Date: Sun, 12 Oct 1997 22:11:13 +0930 From: Mike Smith <mike@smith.net.au> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: hackers@FreeBSD.ORG, tlambert@primenet.com Subject: Re: catching signals... Message-ID: <199710121241.WAA01285@word.smith.net.au> In-Reply-To: Your message of "Sun, 12 Oct 1997 11:28:14 %2B0100." <199710121028.LAA03127@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
> normally, a close() on the audio device will patiently wait for data in > the playout queue to be consumed before returning. However, when a > process using the audio device is aborted with a signal, it would be > probably better to flush the output immediately rather than wait. > > The problem is, (1) how do I discriminate among these two situations > in the driver ? Is there any parameter in the call to close() which > allows me to make the distinction ? In your close(), you are using tsleep() to wait for a wakeup(), correct? Check the return value from tsleep() for EINTR to see if you have been hit by a signal. > Even worse, (2) what do I do when there are multiple references to the same > descriptor, and one is aborted ? Your close() won't be called until the _last_ close of the device. > Some time ago it was pointed out that the interface between the kernel > and the device driver does not notify the driver when a reference to > the device is lost, only when it is acquired through open(). So I guess > for (2) there is no hope to be able to do something sensible. Correct. > I am wondering, would it be reasonable to define and implement a new > interface in the device driver to notify the driver about processes who > reference them ? Multiple consumers should talk to the sound hardware via a multiplexer/ mixer of some sort, eg. nas or something better. There doesn't seem to be any other sensible way to multiplex multiple sound device consumers anyway. ie. what's the point of having a stream output device open by more than one consumer? mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710121241.WAA01285>