[lxc-devel] [PATCH 1/2] Remove process_lock() except where actually needed

[Andrey Mazo]

On Wed, 25 Dec 2013 15:10:33 +0400, Andrey Mazo <mazo at telum.ru> wrote:
> On Tue, 24 Dec 2013 19:05:14 +0400, Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> [snip]
>> And so while I don't like doing so, it sounds like it would be worth
>> wrapping all calls to fork() within the API with a version that
>> frees the process (and static, while it exists) lock(s).  Because
>> unlike lxc_fopen(), this would be needed for all libcs and in
>> perpetuity.  (Ideally we'd be able to do it through linker magic
>> without having to write a wrapper;  else we must have a make rule
>> that kindly warns developers to use lxc_fork() unless a file is
>> tagged as single-threaded).
>>
>> That's just a thought for a future patch, not a request for this patch!
>
> I agree, that this is worth doing as remembering to put process_unlock() after each fork() is quite tedious.
> Linker-based approach should work.
> As far as I can see, the second approach could be implemented either via grepping source file for fork() in Makefile or just defining a macro fork() to cause a compilation error (though these errors may be quite cryptic).
Hmm, I believe, it's possible to use pthread_atfork()'s child fork handler to reset locks to avoid any need of fork() wrappers.
We can setup this handler either during library initialization via __attribute__((constructor)) or on first call to process_lock() (via pthread_once).

[snip]

-- 
Andrey Mazo.