From owner-freebsd-hackers Mon Apr 21 01:14:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA28554 for hackers-outgoing; Mon, 21 Apr 1997 01:14:16 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA28546 for ; Mon, 21 Apr 1997 01:14:10 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id JAA15119; Mon, 21 Apr 1997 09:27:38 +0200 From: Luigi Rizzo Message-Id: <199704210727.JAA15119@labinfo.iet.unipi.it> Subject: concurrent calls to device drivers To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 21 Apr 1997 09:27:37 +0200 (MET DST) Cc: hackers@freebsd.org In-Reply-To: <199704210613.PAA08016@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Apr 21, 97 03:43:31 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [previous thread about possible bug in /dev/spkr ] > The driver claims to only permit a single opener, which as Bruce has > pointed out before is pointless as fd's are duplicated across forks. which reminds me that many device drivers in /sys/i386/isa (some of which were contributed by me... :( ) are "broken" in the same way: they keep a flag to remember that the device is open, but do not prevent concurrent calls, assuming the single open as a guarantee that there are no concurrent calls. The assumption is false not only because of forks, but presumably also when threads are used. At a quick glance the involved devices in /sys/i386/isa are pcaudio, bqu (transputer), asc, gsc, gpib, joy, qcam Perhaps devices should keep a "busy" flag to prevent concurrent calls, rather than limiting to insure a single open. BTW enabling concurrent opens would be kind of useful in some situations; as an example, once (on a couple of DEC with AudioFile) I set up a very simple Internet-phone application with the following: auread | rsh remotehost auplay & rsh remotehost auread | auplay & where auread/auplay are the applications to read/write to the audio device. The same would be possible if we allowed multiple opens to full duplex audio devices (assuming we had a working one...). Perhaps this ought to be a PR ? Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________