Date: Sun, 12 Oct 1997 12:57:45 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: mike@smith.net.au (Mike Smith) Cc: hackers@FreeBSD.ORG, tlambert@primenet.com Subject: Re: catching signals... Message-ID: <199710121157.MAA03278@labinfo.iet.unipi.it> In-Reply-To: <199710121241.WAA01285@word.smith.net.au> from "Mike Smith" at Oct 12, 97 10:10:54 pm
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 ? > > 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? /dev/audio is bidirectional :) 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. for video we are almost used to talk only to the x server because the hardware alone can do almost nothing, and video lends itself very well to multiplexing. For audio, multiplexing is not that easy or obvious so there are too many apps which want to talk directly to the device driver and it would be a nightmare to update them to use the external multiplexer. Of course I could hide the multiplexer behind a portal but that's another layer in the way... and for audio, timing is important. but again, I was thinking of a generic mechanism for all those cases where a device could benefit from knowing how many (or which) processes are accessing it. Cheers Luigi to the device > > mike > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710121157.MAA03278>