4 ms·

I think the only reasonable solution is to completely deprecate functions like setlocale(). Software should just use _l() functions if they want something local

I think the only reasonable solution is to completely deprecate functions like setlocale(). Software should just use _l() functions if they want something localised. Global state considered harmful.

sly010 5y ago
Or in this case locale state considered harmful ;)
worik 5y ago
Global mutable state.....
- stingraycharles 5y ago
  Well if it wasn’t mutable, it wouldn’t be state but just a global constant variable. Which is much less harmful.
  - hinkley 5y ago
    Snapshots are state that has very, very clear boundary conditions. There are lots of relatively sane systems that only allow modification in the interstitial. Of course as scale goes up, finding “before B but after A” breaks down, but we have whole systems running critical infrastructure based on Communicating Sequential Processes, which is the closest we’ve gotten to solving this problem.
mort96 5y ago
FWIW, the tests show that sprintf_l is no faster than sprintf, if you're passing around the same locale object in different threads. So it can help, but it's not an automatic win unless you make sure that each thread keeps a separate locale object.
- nicoburns 5y ago
  Do you understand why the locale object needs to be locked? I would have expected it to be immutable...
  - Akronymus 5y ago
    I assume that its made to be mutable to enable one to change the locale at one point and update it application wide.
  - gumby 5y ago
    Someone could allow users to change locale via an application's interface.
    - rocqua 5y ago
      What about that requires a lock? To prevent reading a half destroyed object? Why not a write lock that allows multiple concurrent readers?
      - gumby 5y ago
        The whole thing is a botch. Sadly, his happens time to time in many standards. More in software than hardware standards in my experience — I wonder why.
  - thayne 5y ago
    There are a lot of things in c one would expect to be immutable or re-entrant that aren't.
- oefrha 5y ago
  The point is if you make sprintf locale-unaware, then your locale-independent calls like sprintf("hello %s", "world") won't be affected by all the locale-locking nonsense that is causing the scaling issue. That's the "win". sprintf_l can be as slow as before if you pass in the same global locale object.
- munch117 5y ago
  Doesn't matter. It's fine for _l functions to be slower, because that's for information being formatted for display, which is inherently low-volume. What matters is to make the non-_l functions faster and more predictable, which is what you achieve by taking locale out of the equation.

I think the only reasonable solution is to completely deprecate functions like setlocale(). Software should just use _l() functions if they want something localised. Global state considered harmful.

sly010 5y ago

Or in this case locale state considered harmful ;)

worik 5y ago

Global mutable state.....

stingraycharles 5y ago
Well if it wasn’t mutable, it wouldn’t be state but just a global constant variable. Which is much less harmful.
- hinkley 5y ago
  Snapshots are state that has very, very clear boundary conditions. There are lots of relatively sane systems that only allow modification in the interstitial. Of course as scale goes up, finding “before B but after A” breaks down, but we have whole systems running critical infrastructure based on Communicating Sequential Processes, which is the closest we’ve gotten to solving this problem.

mort96 5y ago

FWIW, the tests show that sprintf_l is no faster than sprintf, if you're passing around the same locale object in different threads. So it can help, but it's not an automatic win unless you make sure that each thread keeps a separate locale object.

nicoburns 5y ago
Do you understand why the locale object needs to be locked? I would have expected it to be immutable...
- Akronymus 5y ago
  I assume that its made to be mutable to enable one to change the locale at one point and update it application wide.
- gumby 5y ago
  Someone could allow users to change locale via an application's interface.
  - rocqua 5y ago
    What about that requires a lock? To prevent reading a half destroyed object? Why not a write lock that allows multiple concurrent readers?
    - gumby 5y ago
      The whole thing is a botch. Sadly, his happens time to time in many standards. More in software than hardware standards in my experience — I wonder why.
- thayne 5y ago
  There are a lot of things in c one would expect to be immutable or re-entrant that aren't.
oefrha 5y ago
The point is if you make sprintf locale-unaware, then your locale-independent calls like sprintf("hello %s", "world") won't be affected by all the locale-locking nonsense that is causing the scaling issue. That's the "win". sprintf_l can be as slow as before if you pass in the same global locale object.
munch117 5y ago
Doesn't matter. It's fine for _l functions to be slower, because that's for information being formatted for display, which is inherently low-volume. What matters is to make the non-_l functions faster and more predictable, which is what you achieve by taking locale out of the equation.