Re: [alsa-devel] How to close ALSA device nodes?
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...
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,
On Thu, 22 Oct 2009 15:55:33 -0700, Daniel Yek dyek@real.com wrote:
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.
That works if you have a stand-alone program that forks "early", though this really is not too nice. You need to transmit the executable program parameters over some IPC mechanism. Also, this incurs some obvious memory and CPU overhead.
However, most multimedia frameworks are layered into libraries and plugins, so they don't have their own process to fork early enough, so they cannot do that. In my particular bug, we have the ALSA plugin leaking the descriptor, and the XDG screensaver plugin doing fork-and-exec. Synchronizing those two is not really an option.
Rémi Denis-Courmont wrote:
On Thu, 22 Oct 2009 15:55:33 -0700, Daniel Yek dyek@real.com wrote:
Could it be that the answer is to use the surrogate parent model? Book: Pthreads Programming: 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.
That works if you have a stand-alone program that forks "early", though this really is not too nice. You need to transmit the executable program parameters over some IPC mechanism. Also, this incurs some obvious memory and CPU overhead.
However, most multimedia frameworks are layered into libraries and plugins, so they don't have their own process to fork early enough, so they cannot do that. In my particular bug, we have the ALSA plugin leaking the descriptor, and the XDG screensaver plugin doing fork-and-exec. Synchronizing those two is not really an option.
Hi,
[Not trying to say that it is a solution or I know a lot about the model, but just to comment on the possibility more...]
I suppose in the crude way, the program can call the multimedia framework's init function early to fork the surrogate parent and provide forking services. Plugins, etc., should use the framework's service, instead of simply fork.
I further suppose that the a fork-exec DSO can be created and the LD_PRELOAD mechanism used to "redirect" all fork() and exec() (and what-else) to the DSO implementation, which utilizes the DBus 1-to-1 IPC (for convenience, or any custom wire protocol) to the surrogate parent, which then implements fork(), exec(), waitpid(), etc.
I'm not sure yet if DBus provides file-descriptor-passing services, if not, fds can be passed (explicitly -- not great, cumbersome, but it might be necessary) the way it is -- using another Unix domain socket connection, if necessary.
XDG screensaver can be called in a child process too -- the surrogate parent is adequate for this too.
There is a possibility that this model can work, but I have never actually trying it out, just thinking about it often. If this works, it would be a great addition to Glib.
I hope there are other more experienced people chime in to offer (appreciated) comments.
Regards,
[Branch the thread for a separate suggestion...]
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..
<snip>
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.
Is snd_pcm_poll_descriptors() adequate for this particular issue?
Regards,
Le vendredi 23 octobre 2009 21:51:45 Daniel Yek, vous avez écrit :
[Branch the thread for a separate suggestion...]
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..
<snip>
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.
Is snd_pcm_poll_descriptors() adequate for this particular issue?
That tells the application what descriptors to poll for ALSA to use. That does not tell what the descriptors do. So re-using those descriptors across exec() would be very far-fetched.
participants (2)
-
Daniel Yek -
Rémi Denis-Courmont