On Sat, Nov 17, 2018 at 09:42:51PM +0100, Julian Andres Klode wrote: > If it has been called, they return a thread local version > instead. This allows existing code to work unchanged, at > a slight performance hit (though, _config tree lookups > probably are far worse than figuring out whether _config > is tls or not). I have no real-world experience with threads, so I will opt to keep silent about it to appear clever rather than say something and blow my cover… but: An example of existing code which deploys threads but needs to share _config is our aptwebserver (as it wants to reconfigure on the fly). Other usecases very likely don't want their config to be changed through (and even in the webserver its a bit strange… but a saner implementation would like turn out to be a massive overkill for this webserver). _system mostly deals with locking and I wonder if here you don't have cases as well in which some tools want to work this diverse that the threads can vs. can't work with the same locks – e.g. two threads splitting the 'clean' command in chunks vs. two threads installing packages. Having _error in this one thread-local is okayish – and the stack pushing dance you can perform is very much anti-global –, but there might be a reason for a thread to say: Take my local errors and escalate them to global (potentially merging them with the other locals reporting back) – maybe on explicit request. So perhaps that needs some fine control over which of these are shared or not between threads rather than a "global" switch for them all. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature