On Wed, 25 Dec 2013 15:10:33 +0400, Andrey Mazo <[email protected]> wrote:
On Tue, 24 Dec 2013 19:05:14 +0400, Serge Hallyn <[email protected]>
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.
_______________________________________________
lxc-devel mailing list
[email protected]
http://lists.linuxcontainers.org/listinfo/lxc-devel
