On Fri, Apr 04, 2008 at 09:57:36AM -0400, Lon Hohberger wrote:
> 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.
It's a tiny amount of memory. And you want to keep the
registrations if you are not exec(2)ing, as you may fork again.
> 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.
Combine them. log_printf() watches PIDs and returns errors if
the PID has changed. The user must call something to initialize the new
thread of control. Sure, the user now has to do this, but it's a very
clean model - "Every independent thread of control must call
foo_init()". That sort of thing.
--
"Depend on the rabbit's foot if you will, but remember, it didn't
help the rabbit."
- R. E. Shay
Joel Becker
Principal Software Developer
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais
