[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Thread-safe apt



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


Reply to: