Date: Mon, 08 Apr 1996 11:53:43 -0700 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> To: Thomas Roell <roell@blah.a.isar.de> Cc: hackers@FreeBSD.ORG, roell@xinside.com Subject: Re: The F_SETOWN problem.. Message-ID: <199604081853.LAA02584@rah.star-gate.com> In-Reply-To: Your message of "Mon, 08 Apr 1996 11:47:34 %2B0200." <199604080947.LAA00308@blah.a.isar.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604081853.LAA02584>