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).
and the problem is exactly what you wrote above.
it's difficult to get fds if the plugin becomes complex.
hence, i propose to create a new function as analogy to
snd_pcm_nonblock():
int snd_pcm_set_close_at_exec(snd_pcm_t *pcm, int close);
applications need to call only this for every type of pcm.
comments please?
Takashi
-------------------------------------------------------
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
