Thread-safe apt

[Julian Andres Klode <jak@debian.org>]

Hi folks,

this is a summary of my plans for thread safe apt. I think
I posted that a year or two ago already, but let's go
again.

# Basic idea

Currently, we have a few static variables and a few external variables
that are shared between threads.

The two public problematic non-TLS variables are _config and
_system:

    apt-pkg/contrib/configuration.h:extern Configuration *_config;
    apt-pkg/pkgsystem.h:extern pkgSystem *_system;

My proposal is to redefine _system and _config like this

    #define _config _getConfig()
    #define _system _getSystem()

and introduce a new function called APT::threadInit() or
APT::initThread(). If the function has not been called,
_getConfig() returns old _config, and _getSystem() returns
old _system.

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).

# Context objects

Taking this further, we can store these thread-local information
in a context object. While changing the API everywhere to accomodate
for a context object is a bit too much involved, we can at least
provide functions to modify the current context, for example.

    {
        APT::WithContext withContext(&myContext);

        // Code here runs in the context "myContext"
    }

    // Code here runs in previous context

I don't think we should provide a way to retrieve the current
context or a non-RAII way to switch it to reduce the

# ABI, API

Uf you initialize threads in your application, all libraries using
libapt-pkg need to be compiled against the new apt so they see the
same _system and _config as your program.

But this can be done on a case-by-case basis as necessary, and does
not require an ABI or API break.

# Open questions

1. _error is already thread-local. Should we just keep it that way,
   or should we associate it with contexts. How much effort is that?
2. How do we deal with locks in multiple contexts. We need to make sure
   that only one context holds a file descriptor for a given lock file,
   as otherwise, closing the file in one context releases the lock in
   another.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en