On Fri, 4 Apr 2008, Lon Hohberger wrote: > > 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.
can we wrap this into our_fork() kind of thing? > > 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. there are too many calls you can do to wrap them all. It's probably best to reinit once and for all. > 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 prefer the transparent option as user. I don't really need to care too much what's happening in background to have a printf working kind of thing. > I can look at liblogsys and propose something, but I can't do it for a > few days. Thanks that would be awesome. Fabio -- I'm going to make him an offer he can't refuse. _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
