How to close ALSA device nodes?

How to close ALSA device nodes?

[Rémi Denis-Courmont]

	Hello,

I'm getting a bug report against VLC media player whereby ALSA sound output 
stops working when the screensaver is inhibited. It turns out that VLC is 
leaking any file descriptor open through ALSA-lib into child processes. The 
exact same issue was already raised by mplayer... 6 years ago:
http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg06249.html

In other cases (V4L, OSS, DVB, DVD, sockets, even regular files...), VLC would 
open the device nodes with O_CLOEXEC flag (if supported by kernel and libc) 
and fallback to setting FD_CLOEXEC via fcntl(). Then the descriptor is 
automatically, and in the earlier case, thread-safely, closed whenever VLC -
forks and- execs. With ALSA-lib, I cannot figure any way to achieve that...

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?

Best regards,

-- 
Rémi Denis-Courmont
http://www.remlab.net/
_______________________________________________
vlc-devel mailing list
To unsubscribe or modify your subscription options:
http://mailman.videolan.org/listinfo/vlc-devel

How to close ALSA device nodes?

[Rémi Denis-Courmont]

	Hello,

I'm getting a bug report against VLC media player whereby ALSA sound output 
stops working when the screensaver is inhibited. It turns out that VLC is 
leaking any file descriptor open through ALSA-lib into child processes. The 
exact same issue was already raised by mplayer... 6 years ago:
http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg06249.html

In other cases (V4L, OSS, DVB, DVD, sockets, even regular files...), VLC would 
open the device nodes with O_CLOEXEC flag (if supported by kernel and libc) 
and fallback to setting FD_CLOEXEC via fcntl(). Then the descriptor is 
automatically, and in the earlier case, thread-safely, closed whenever VLC -
forks and- execs. With ALSA-lib, I cannot figure any way to achieve that...

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?

Best regards,

-- 
Rémi Denis-Courmont
http://www.remlab.net/
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: How to close ALSA device nodes?

[Robert Hancock]

2009/10/18 Rémi Denis-Courmont <rem@videolan.org>:
>        Hello,
>
> I'm getting a bug report against VLC media player whereby ALSA sound output
> stops working when the screensaver is inhibited. It turns out that VLC is
> leaking any file descriptor open through ALSA-lib into child processes. The
> exact same issue was already raised by mplayer... 6 years ago:
> http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg06249.html
>
> In other cases (V4L, OSS, DVB, DVD, sockets, even regular files...), VLC would
> open the device nodes with O_CLOEXEC flag (if supported by kernel and libc)
> and fallback to setting FD_CLOEXEC via fcntl(). Then the descriptor is
> automatically, and in the earlier case, thread-safely, closed whenever VLC -
> forks and- execs. With ALSA-lib, I cannot figure any way to achieve that...
>
> 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..

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

Re: How to close ALSA device nodes?

[Rémi Denis-Courmont]

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

Re: How to close ALSA device nodes?

[Daniel Yek]

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@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: How to close ALSA device nodes?

[Rémi Denis-Courmont]

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

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Surrogate Parent Model / How to close ALSA device nodes?

[Daniel Yek]

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,

-- 
Daniel Yek.




_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: How to close ALSA device nodes? / ALSA's fds

[Daniel Yek]

[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,

-- 
Daniel Yek.


_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: How to close ALSA device nodes? / ALSA's fds

[Rémi Denis-Courmont]

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.

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