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&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 <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... > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
