Re: [Alsa-devel] [BUG] alsa-lib leaves sound device open for childprocesses
On Wed, 12 Feb 2003, Takashi Iwai wrote:
At Sat, 8 Feb 2003 20:53:14 +0100 (CET),
Jaroslav wrote:
On Sat, 8 Feb 2003, Sebastian Kapfer wrote:
On Sat, 8 Feb 2003 12:50:01 +0100 (CET)
Jaroslav Kysela [EMAIL PROTECTED] wrote:
All of the remaining applications should be
considering what will happen to their resources on
exec(), and I see no reason why careless programmers
should have a few of their bugs swept under the rug
for them.
I fully agree here.
Can anyone comment on exactly how an alsa-lib client app should make
sure that exec'd processes don't inherit file handles? I can't find a
way to know the FD number which alsa-lib uses. snd_pcm_file_descriptor
is gone. What replaced it?
The applications should use snd_pcm_close() function (or related one
snd_*_close()). Note that more complex plugins can use more file
descriptors so the application is not able to enumerate them.
maybe it's just whipping a dead horse, but let me take this issue back
again.
there might be some situations in which you cannot call *_close()
functions. for example, if you are sharing the handle with several
threads and want to start an external program from one of the
threads.
in such a case, the only correct method is to call fcntl(CLOEXEC).
Not really:
int i = sysconf(_SC_OPEN_MAX);
while (--i = 3) {
if (i != do_not_close_fd[])
close(i);
}
exec(...);
But it's true that the application cannot filter ALSA's file descriptors
in this case (to pass only specific interfaces to executed process). We
have similar troubles with shm.
I'd propose to have a function 'snd_pcm_free_system_resources()' which
will close all open file descriptors, detaches all shm handles and cleans
all resources necessary before exec() or after fork():
int snd_pcm_free_system_resources(snd_pcm_t *pcm, int memory);
When memory != 0, it will free all memory resources.
Jaroslav
-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [BUG] alsa-lib leaves sound device open for childprocesses
On Sat, 8 Feb 2003, Sebastian Kapfer wrote: On Sat, 8 Feb 2003 12:50:01 +0100 (CET) Jaroslav Kysela [EMAIL PROTECTED] wrote: All of the remaining applications should be considering what will happen to their resources on exec(), and I see no reason why careless programmers should have a few of their bugs swept under the rug for them. I fully agree here. Can anyone comment on exactly how an alsa-lib client app should make sure that exec'd processes don't inherit file handles? I can't find a way to know the FD number which alsa-lib uses. snd_pcm_file_descriptor is gone. What replaced it? The applications should use snd_pcm_close() function (or related one snd_*_close()). Note that more complex plugins can use more file descriptors so the application is not able to enumerate them. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [BUG] alsa-lib leaves sound device open for childprocesses
On Mon, 3 Feb 2003, Sebastian Kapfer wrote:
The alsa-lib doesn't set the close-on-exec flag on its PCM device FD's.
The consequence is that processes spawned by alsa-lib clients inherit an
open file handle to the PCM device and thereby block it.
For example, mplayer can disable and re-launch the xscreensaver daemon.
In the alsa-enabled version of mplayer, the xscreensaver process
inherits a pcm handle, although xss can't make use of it. This
effectively forces me to restart xss manually after each mplayer
session.
Suggested fix:
--- src/pcm/pcm_hw.c.orig 2002-10-12 13:49:54.0 +0200
+++ src/pcm/pcm_hw.c 2003-02-03 23:07:14.0 +0100
@@ -867,6 +867,11 @@
ret = -errno;
goto _err;
}
+ if( fcntl( fd, F_SETFD, FD_CLOEXEC ) != 0 ) {
+ SYSERR(fcntl FD_CLOEXEC failed);
+ ret = -errno;
+ goto _err;
+ }
if (ioctl(fd, SNDRV_PCM_IOCTL_PVERSION, ver) 0) {
SYSERR(SNDRV_PCM_IOCTL_PVERSION failed);
ret = -errno;
Well, I and Abramo think that it's better to force application developers
to clean allocated things before they'll call exec(). I believe that not
only ALSA file descriptors are open after exec() in mplayer.
Jaroslav
-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
