[alsa-devel] How to close ALSA device nodes?
dyek at real.com
Fri Oct 23 00:55:33 CEST 2009
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
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
>>> 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
> 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.
>> 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
More information about the Alsa-devel