From owner-freebsd-hackers  Mon Apr  8 11:54:58 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id LAA16516
          for hackers-outgoing; Mon, 8 Apr 1996 11:54:58 -0700 (PDT)
Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA16499
          for <hackers@FreeBSD.ORG>; Mon, 8 Apr 1996 11:54:48 -0700 (PDT)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id LAA02584; Mon, 8 Apr 1996 11:53:44 -0700
Message-Id: <199604081853.LAA02584@rah.star-gate.com>
X-Mailer: exmh version 1.6.5 12/11/95
To: Thomas Roell <roell@blah.a.isar.de>
cc: hackers@FreeBSD.ORG, roell@xinside.com
Subject: Re: The F_SETOWN problem.. 
In-reply-to: Your message of "Mon, 08 Apr 1996 11:47:34 +0200."
             <199604080947.LAA00308@blah.a.isar.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 08 Apr 1996 11:53:43 -0700
From: "Amancio Hasty Jr." <hasty@rah.star-gate.com>
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Now if we had a mechanism like ast delivery in VMS you wouldn't be having
all this problems. 8)

I often wonder why the kludgy asynch signal notification was not taken 
a step further to implement full asynchronous i/o .

Aside from that tty drivers would have to be split into two parts:
one to do the i/o at a high priority and the other half to process
the tty events.

	Amancio

>>> Thomas Roell said:
 > In your message of 8 April 1996 you write:
 > 
 > > > The fix here is to virtualize all mouse I/O in the kernel instead of
 > > > presenting seperate abstractions that the X server has to deal with.
 > > 
 > > This would be a wonderful idea.  Except that convincing a vendor like
 > > SunSoft or SCO that your new spiffo mouse protocol was Just The Thing
 > > might not be so easy. 8(
 > 
 > It's even worse. What if you want to add support for a new graphics
 > tablet ? Relink the kernel, and add a kernel driver ? This is kind of
 > too much for the avare end user. I could do this with SVR4, which
 > allows to push STREAMS modules ontop of let's say a serial device. But
 > still it's to complex to be used realitically.
 > 
 > > > b)	You are taking too long in your atomaton before getting back
 > > > 	to the state where the buffered events can be processed, and
 > > > 	you need to fix the automaton.
 > > 
 > > Not being anything of an Xpert, I can only suggest that the automaton is
 > > as it is for the sake of efficiency.  Breaking it down and persistently
 > > selecting may well significantly degrade its performance.
 > 
 > Right. You have two ways with the current scheduling. Either increase
 > temporal performance by decreasing interactivty, or increasing
 > interactivity by decreasin overally performance. The only way to get
 > out of this deadlock is either to seperate the device-io from the
 > client-io, or use a dynamic schedluing, which then again solves only
 > part of the problem.
 > 
 > - Thomas
 > -- 
 > Denver Office                THOMAS ROELL        /\      Das Reh springt hoc
     h,
 > +1(303)298-7478              X INSIDE INC       /  \/\   das Reh springt wei
     t,
 > 1801 Broadway, Suite 1710                      /    \ \/\     was soll es tu
     n,
 > Denver, CO 80202           roell@xinside.com  / Oelch! \ \     es hat ja Zei
     t.
 >