Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Apr 1996 11:59:37 +0930 (CST)
From:      Michael Smith <msmith@atrad.adelaide.edu.au>
To:        terry@lambert.org (Terry Lambert)
Cc:        roell@blah.a.isar.de, msmith@atrad.adelaide.edu.au, terry@lambert.org, hackers@FreeBSD.ORG, jkh@time.cdrom.com, roell@xinside.com
Subject:   Re: The F_SETOWN problem..
Message-ID:  <199604080229.LAA08202@genesis.atrad.adelaide.edu.au>
In-Reply-To: <199604072000.NAA00425@phaeton.artisoft.com> from "Terry Lambert" at Apr 7, 96 01:00:57 pm

next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert stands accused of saying:
> 
> Is there some reason you can't just increase the buffer in the kernel
> to prevent an overflow, if you insist on long delay state processing
> of many events without going back out to the top level of the I/O
> automaton?

Because many commercial eunuchs don't provide this as an option.  TR is
looking for a portable solution.

> 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(

> Really, a buffer overflow is telling you one of two things:
> 
> a)	Your event buffer is too small

This is obvious.  However, the buffer size is effectively fixed.

> 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.

> 					Terry Lambert

-- 
]] Mike Smith, Software Engineer        msmith@atrad.adelaide.edu.au    [[
]] Genesis Software                     genesis@atrad.adelaide.edu.au   [[
]] High-speed data acquisition and      (GSM mobile) 0411-222-496       [[
]] realtime instrument control          (ph/fax)  +61-8-267-3039        [[
]] Collector of old Unix hardware.      "Where are your PEZ?" The Tick  [[



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604080229.LAA08202>