On Thu, 6 Feb 2003 23:10:34 +0000 (GMT) Chris Rankin <[EMAIL PROTECTED]> wrote:
> --- Sebastian Kapfer <[EMAIL PROTECTED]> wrote: > > I can find a use for stdio FD's > > in the new process either. The exec'd process can't > > even know which FD corresponds to which file. > > I'm assuming from the context of your message that you > meant "CAN'T find a use ... either". You're right, sorry :) > But the whole point of a general purpose API (which is what libc is > and presumably is what ALSA aspires to have) is to > support *ALL* possible uses, whether you can imagine > them or not. Setting FD_CLOEXEC automatically doesn't make the library less powerful. You can still unset the flag yourself __if you really need the feature__ of inherited ALSA FD's. But wouldn't FD_CLOEXEC be the "reasonable default" setting, which is correct for 99% of all applications? > It is the height of arrogance to assume that something has no use > simply because you can't imagine using it. I'm not implying that this feature should be banned... in fact it can't be banned. As long as the programmer can retrieve the underlying FD number from the ALSA library, he can always (un)set FD_CLOEXEC. My point is that the current default behaviour is (at least IMHO) unfortunate. -- Best Regards, | Hi! I'm a .signature virus. Copy me into Sebastian | your ~/.signature to help me spread! ------------------------------------------------------- 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
