On 04/02/2015 02:13 PM, Dan Ackroyd wrote: > Adam Harvey wrote: >> What about just adding another function: setlocale_global(), or similar? > > Do you mean setlocale would become the thread safe one, and > setlocale_global() would be the current behaviour? If so, that would > be a BC break for the small number of people who are deliberately > using setlocale globally. We could do that at a major version I guess. > > I think the ini setting is still better - it allows people to use code > that was written assuming that setlocale was safe to use, rather than > forcing them to change it. > > It might be best to introduce both setlocale_ts() and > setlocale_global(), so that users could call either explicitly, and > have the ini setting control which one setlocale() points to. If we > did that we could also then plan to eventually deprecate both the ini > setting and the plain setlocale without _ts/_global. > > Ryan Pallas wrote: >> I like the idea of an INI actually, but I would make it default to the >> current behaviour and user education so those who need TS know to change it. > > The problem with that is that for people who aren't aware of the > setting, they wouldn't know that they need to change the setting. > Instead they just want their code to work properly 'out of the box'. > For the vast majority of people calling the thread safe version of > setlocale would be what they problem want it to do, and so PHP should > default to the right thing for the majority of people. > > Of course there is a separate argument about changing the behaviour at > major/minor version, and if this was introduced then having to > `thread_safe_setlocale=off` for 7.1 and `thread_safe_setlocale=on` for > 8 could be correct.
A step back here, please. Which concrete problem are you actually trying to solve? HHVM needed this fix because of its single-process threaded architecture on UNIX. PHP is not typically threaded on UNIX, so it doesn't seem like an issue affecting very many people. It has been on our radar for ages and has a big prominent red warning box about it in the documentation. Threaded use of PHP on UNIX tends to be rather specialized cases by people who understand that things like setlocale() and putenv() are process-wide. That doesn't mean there is anything wrong with implementing thread-local setlocale for our threadsafe builds, and we should definitely fix any in-process setlocale interference issues, but the thread safety part of it just doesn't seem like something very many people are going to care about. Why do you? -Rasmus
signature.asc
Description: OpenPGP digital signature
