From owner-freebsd-hackers  Sun Oct 12 06:16:30 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA20119
          for hackers-outgoing; Sun, 12 Oct 1997 06:16:30 -0700 (PDT)
          (envelope-from owner-freebsd-hackers)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA20108
          for <hackers@FreeBSD.ORG>; Sun, 12 Oct 1997 06:16:18 -0700 (PDT)
          (envelope-from luigi@labinfo.iet.unipi.it)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id MAA03278; Sun, 12 Oct 1997 12:57:45 +0100
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199710121157.MAA03278@labinfo.iet.unipi.it>
Subject: Re: catching signals...
To: mike@smith.net.au (Mike Smith)
Date: Sun, 12 Oct 1997 12:57:45 +0100 (MET)
Cc: hackers@FreeBSD.ORG, tlambert@primenet.com
In-Reply-To: <199710121241.WAA01285@word.smith.net.au> from "Mike Smith" at Oct 12, 97 10:10:54 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > 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
> 
>