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...