Could it be that the answer is to use the surrogate parent model?
Book: Pthreads Programming:
http://books.google.com/books?id=2kZDx8H6H18C&pg=PA190&lpg=PA190&...
http://books.google.com/books?id=2kZDx8H6H18C&pg=PA190&lpg=PA190&dq=Multithreading+surrogate+parent+model&source=bl&ots=nmEnmuPQme&sig=-MvAQEZUJngOdMLJ-HGhAqCv1AU&hl=en&ei=_eDgSqWYLYacsgOB_eHODA&sa=X&oi=book_result&ct=result&resnum=1&ved=0CAwQ6AEwAA#v=onepage&q=&f=false
That is, the multi-threaded app. creates a dummy child process during
its initialization process and use the child solely as a surrogate
parent to fork on behalf of the app. That way, the multi-threaded app.
doesn't have to fork and possibly leaking "states" in the child
(especially, if it is not followed by an exec(), I think.)
I'm interested in hearing from the more experienced devs. regarding this
technique too.
Regards,
--
Daniel Yek.
Rémi Denis-Courmont wrote:
> Le dimanche 18 octobre 2009 20:13:15 Robert Hancock, vous avez écrit :
>>> From the earlier thread, I reckon that ALSA developers consider that
>>> this
>>> is an upper-layer issue. Maybe so, but then how is the upper-layer
>>> supposed to find which file descriptors ALSA-lib has opened - if any?
>>> Conversely, if ALSA- lib won't tell while file descriptors it is using,
>>> what could possibly be the use case for not closing those on exec?
>> I agree that it's a difficult problem for an app that wants to fork
>> and exec another process.. I'd think really should be some way for an
>> app to control the CLOEXEC flag for the file descriptors that alsa-lib
>> has open..
>
> Right. The kernel recently introduced the O_CLOEXEC open flag, to support
> thread-safe close-on-exec. The only way to leverage this is for
> ALSA-lib to
> set close-on-exec itself when it opens a file (whether by default or
> when the
> application requests it).
>
> That said, I still fail to see any potential use case to not set the
> flag.
> Since ALSA-lib won't let the application know about the file handles, any
> application cannot a use them across exec() in the first place. For the
> reference, glibc is now setting close-on-exec in similar cases, e.g.
> syslog().
>
>> I guess the alternative would be to shutdown all open PCMs, etc. in
>> ALSA in the child process after forking and before the exec, so that
>> they don't end up still open for the new process..
>
> I suspect such an approach would be painful both for ALSA and for the
> applications. From ALSA, this would need safety with regards to fork in
> another thread. That probably requires pthread_atfork() *glurp* if
> ALSA is to
> keep its SMP & thread-safety promise *ouch*. From the application, this
> require calling an ALSA function between fork and exec. That would forbid
> using system(), popen() or -faster- posix_spawn*(). That also means
> linking to
> ALSA in every place that executes. Considering that VLC is heavily plugin-
> based, this would be so impractical that I'd even rather scan through
> /proc/self/fd...
>
