On Fri, 2008-04-04 at 14:45 +0200, Fabio M. Di Nitto wrote:
> On Fri, 4 Apr 2008, Lon Hohberger wrote:
> 
> >
> > On Fri, 2008-04-04 at 14:29 +0200, Fabio M. Di Nitto wrote:
> >> Hi Lon and Steven,
> >>
> >> i found a bug in liblogsys and i have no idea how to fix it.
> >>
> >> In attachment there is the smallest test case i could write.
> >>
> >> Build with:  gcc -Wall -O0 -ggdb test.c -L/usr/lib/openais -llogsys
> >> or similar.. please keep liblogsys shared as it should be in the final
> >> application.
> >>
> >> The problem is that logsys init doesn't survive a fork() used to daemonize
> >> (like many applications do).
> >
> > pthread_atfork needed?
> 
> where? seriously.. this thing is giving me headache....

So - basically, my thought was that fork() shouldn't suddenly break
stuff.

I haven't looked at the logsys lib in awhile, but generally speaking,
libraries which use threading models to accomplish stuff usually need
some immediate reinitialization after fork() in the child process.

One solution is to register a pthread_atfork() for the child side of the
fork to respawn the logging thread in the child process and reinitialize
any mutexes which are there.  Forking with the mutex held by another
thread would result in a hang in the child process, obviously, because
the mutex state would be copied.  The problem with registering an atfork
handler is that if you use it incorrectly, you could leak memory.
pthread_atfork doesn't cancel registrations after a fork nor does fork()
free the memory allocated by a pthread_atfork() registration.

Another option would be to have log_printf() watch PIDs and if the PID
changes, reinit the subsystem (thread(s), mutex(es)) for the user
transparently.

A third option would be to have the user call something simple to do
this work in the child process, though this is the least transparent at
the API level (and is a bit annoying), but it's also very clean -
particularly if the child process doesn't actually need to use liblogsys
due to an immediate exec() afterwards.

I can look at liblogsys and propose something, but I can't do it for a
few days.

-- Lon

_______________________________________________
Openais mailing list
Openais@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais

Reply via email to