From owner-freebsd-hackers Sun Oct 12 06:50:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA21581 for hackers-outgoing; Sun, 12 Oct 1997 06:50:59 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA21571 for ; Sun, 12 Oct 1997 06:50:38 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id XAA01454 for ; Sun, 12 Oct 1997 23:17:42 +0930 (CST) Message-Id: <199710121347.XAA01454@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: hackers@FreeBSD.ORG Subject: Re: catching signals... In-reply-to: Your message of "Sun, 12 Oct 1997 12:57:45 +0100." <199710121157.MAA03278@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 Oct 1997 23:17:41 +0930 From: Mike Smith 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 ? 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