From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [BUG] alsa-lib leaves sound device open for child processes Date: Fri, 07 Feb 2003 17:13:10 +0100 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <20030207135848.567.qmail@web40611.mail.yahoo.com> Mime-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <20030207135848.567.qmail@web40611.mail.yahoo.com> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: Chris Rankin Cc: Paul Davis , alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At Fri, 7 Feb 2003 13:58:48 +0000 (GMT), Chris Rankin wrote: > > --- Paul Davis wrote: > > there's a little detail you're forgetting. unless > > the hw supports multi-open and the current number of > > subunits is below the limit of the number of opens, > > then having the descriptor will cause all other > > attempts to access the device to block (unless they > > explicitly request non-blocking open, which means > > they then have to unset that flag for normal > > application operation > > I hadn't forgotten. The situation to which you are > referring is called "a bug in the *application*". > Determining the destinies of resources, delivery of > signals etc when spawning child processes is the > application-programmer's responsibility. > > And yes, I have tracked down bugs like this before. > And I *did* fix the application. i don't think it's a bug of the alsa-lib, too. it's a bug of mplayer. mplayer should be fixed. period. but, the problem is that this kind of bugs can be rarely found (nor appear). on the contrary, if FD_CLOEXEC is set, you'll be able to notice what's wrong. that's what i mentioned "safer". Takashi ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com