From owner-freebsd-hackers  Sun Jul 23 17:33:16 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id RAA21182
          for hackers-outgoing; Sun, 23 Jul 1995 17:33:16 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id RAA21175
          for <hackers@freebsd.org>; Sun, 23 Jul 1995 17:33:03 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id KAA27013; Mon, 24 Jul 1995 10:23:39 +1000
Date: Mon, 24 Jul 1995 10:23:39 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199507240023.KAA27013@godzilla.zeta.org.au>
To: ache@astral.msk.su, terry@cs.weber.edu
Subject: Re: dial up at > 9600 baud
Cc: bde@zeta.org.au, hackers@freebsd.org, harry@hgac.com,
        jkh@violet.berkeley.edu
Sender: hackers-owner@freebsd.org
Precedence: bulk

>It's also broken because the wait for DCD on the blocking open is
>only in effect when the open count is 0.  After one open as a
>non-blocking open, the reference count is one, and subsequent opens
>are not *supposed* to block.

I disagree.  POSIX requires it to block.  Not blocking would cause
stupid behaviour such as `stty -f /dev/ttyd0' unblocking any getty
sleeping in open for /dev/ttyd0.  Once the open has completed it is
hard to recover.

1.1.5 fiddles with the open count to make blocking work.  There
can be any number of processes sleeping in open() and any number
of processes with it open (having opened it in nonblocking mode).

2.x doesn't fiddle with the open count yet, so blocking doesn't
work right if there is one or more nonblocking opens such as the
`stty -f' mentioned above.

Bruce