From owner-freebsd-hackers Sun Apr 7 19:03:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA19069 for hackers-outgoing; Sun, 7 Apr 1996 19:03:28 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA19063 for ; Sun, 7 Apr 1996 19:03:22 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id LAA08202; Mon, 8 Apr 1996 11:59:38 +0930 From: Michael Smith Message-Id: <199604080229.LAA08202@genesis.atrad.adelaide.edu.au> Subject: Re: The F_SETOWN problem.. To: terry@lambert.org (Terry Lambert) Date: Mon, 8 Apr 1996 11:59:37 +0930 (CST) Cc: roell@blah.a.isar.de, msmith@atrad.adelaide.edu.au, terry@lambert.org, hackers@FreeBSD.ORG, jkh@time.cdrom.com, roell@xinside.com In-Reply-To: <199604072000.NAA00425@phaeton.artisoft.com> from "Terry Lambert" at Apr 7, 96 01:00:57 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 [[