Re: How to close ALSA device nodes? - Rémi Denis-Courmont

From: "Rémi Denis-Courmont" <rem@videolan.org>
To: alsa-devel@alsa-project.org
Subject: Re: How to close ALSA device nodes?
Date: Sun, 18 Oct 2009 20:38:34 +0300	[thread overview]
Message-ID: <200910182038.34252.rem@videolan.org> (raw)

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

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel