I am using vfork()
in glibc and according to vfork()
's man page:
Fork handlers established using pthread_atfork(3) are not called when a multithreaded program employing the NPTL threading library calls vfork(). Fork handlers are called in this case in a program using the LinuxThreads threading library.
On NPTL fork handlers are not being called.
In my specific case I need this protection to be engaged so fork handlers will be called the same way as when calling fork()
.
Is there a way to cause pthread library to call registered handlers or even call them manually?
I thought of using clone()
as it gives more precise control of the cloned process but it also avoids fork handlers:
Handlers registered using pthread_atfork(3) are not executed during a clone call.
Also read how to reset handlers registered by pthread_atfork - in my case I don't want to remove handlers but only call them.
Thanks.
If you succeeded in doing this, your program would become corrupt. There is a reason
pthread_atfork
handlers aren't called onvfork
.A typical usage of
pthread_atfork
handlers is to guarantee that any locks held in the parent process are in a consistent state in both the child and the parent after thefork
.Without handlers, suppose thread
T1
is holding lockL
, and threadT2
callsfork
. Since onlyT2
will be replicated into the child,L
will remain locked forever. IfT2
needs that lock (say it was themalloc
lock),T2
will deadlock (withT1
which doesn't exist in the child).The solution:
pthread_atfork
handlers. In the parent processprepare()
will acquireL
, and bothparent()
andchild()
handlers will unlock their own instance ofL
in the parent and child processes respectively. Everything is happy1.Now consider what happens if you do the same after
vfork
.prepare()
acquiresL
as expected, but when you callparent()
andchild()
, they unlock the same instance ofL
(because parent and child processes share memory). ThusL
gets unlocked twice, corrupting it!1 In practice calling either
fork
orvfork
in a multithreaded program is fraught with peril, and doing this safely in the presence of arbitrary libraries is near impossible.