Date: Sun, 12 Oct 1997 23:17:41 +0930 From: Mike Smith <mike@smith.net.au> To: hackers@FreeBSD.ORG Subject: Re: catching signals... Message-ID: <199710121347.XAA01454@word.smith.net.au> In-Reply-To: Your message of "Sun, 12 Oct 1997 12:57:45 %2B0100." <199710121157.MAA03278@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. > > unfortunately the signal might occur during a previous tlseep (e.g. > within a write()) and the close is called at exit by the default > handler. I don't think singla persist after they are caught, right ? You are concerned about an application hanging after it has been killed by a signal, as opposed to not having the device close be stoppable. I don't think that this is something worth worrying about, TBH. You might want to consider honouring the non-blocking flag on the last-close file descriptor, but that's not a complete solution. > > 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? > > /dev/audio is bidirectional :) Sounds like a bogus compatability interface then. 8) > In any case I was thinking of a general mechanism unrelated to > audio, which is only one application. An external multiplexer is > a viable solution but it makes you lose the nice property of being > able to talk directly to the device for those tasks that the device > can do directly. Understood. I am sure that there would be interest in such a mechanism as you propose; a device should perhaps be able to indicate that every time a new reference to it is created that its open() should be called, and every time one is run down its close() should be called. Obviously this would not be the default behaviour. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710121347.XAA01454>