Date: Sun, 7 Apr 1996 14:45:57 +0200 From: Thomas Roell <roell@blah.a.isar.de> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: terry@lambert.org (Terry Lambert), hackers@FreeBSD.ORG, jkh@time.cdrom.com, roell@xinside.com Subject: Re: The F_SETOWN problem.. Message-ID: <199604071245.OAA00414@blah.a.isar.de> In-Reply-To: <199604071247.WAA06437@genesis.atrad.adelaide.edu.au> References: <199604070021.RAA28693@phaeton.artisoft.com> <199604071247.WAA06437@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In your message of 7 April 1996 you write: > > I assume you want this for SIGHUP processing? I used to work (for > > more than 5 years) as THE software engineer (not including the > > company president) for the #1 UNIX communications software (TERM). > > Er, almost certainly not. Try "low-cost asynchronous input". Remember > what TR does? Think about how handy it would be to do your mouse data > handling inside a signal handler; your main loop would be presented > with events out of a FIFO as faits accompli, you could probably even > stuff the location registers in the signal handler. Was it that obvious ;-) Actually two reasons why I need it. One is obviously that the mouse responds more rapidly to movements. And this gets critical if the machine is under heavly load (both from the number of processes and from the number of X-Requests hogging the X-Server). Of course you can move the mouse pointer directly in the signal handler (although this is EXTREMELY tricky). The other reasons is more tricky. We do have reports from people that under heavy load they loose sync of the PS/2 mouse. The PS/2 mouse is different from all other mice, as there is now way to figure out from the byte-stream when a 3 byte packet starts. There is supposed to be a sync-bit, but half of the PS/2 mice do not set it. The PS/2 kernel driver in FreeBSD (and much worse in Interactive UNIX) has only a limited buffer. Assume you have 1024 bytes, then you can buffer only 341 packets (and one additional byte). If the mouse reports 50 times per second the position, then after roughly 7 seconds you loose sync if you are unable to read the input (3 seconds with ISC). If you run now X-clients which are hogging the X-server with requests that are longrunning (like mpeg_play) and you move the mouse for a while you might want to restart the X-server to get the mouse into sync again. >From the discussion here (and the fact that only LINUX and SVR4 seem to be able to do SIGIO/SIGPOLL correctly) such an io-daemon seems to be a reasonable, but less desirable solution. Or, of course a seperate pthread. - Thomas -- Denver Office THOMAS ROELL /\ Das Reh springt hoch, +1(303)298-7478 X INSIDE INC / \/\ das Reh springt weit, 1801 Broadway, Suite 1710 / \ \/\ was soll es tun, Denver, CO 80202 roell@xinside.com / Oelch! \ \ es hat ja Zeit.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604071245.OAA00414>