Re: [wmii] wmii-3.1 bug (fix): libixp overload

From: Suraj N. Kurapati <skurapat_AT_ucsc.edu>
Date: Wed, 20 Sep 2006 12:45:04 -0700

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Denis Grelich wrote:
> On Wed, 20 Sep 2006 02:24:53 -0700
> "Suraj N. Kurapati" <skurapat_AT_ucsc.edu> wrote:
>
>> Now, because wmii-4 does not continually stream events to you (even
>> after the read request was finished), there is a possibility that
>> you may miss out on events. That is, when you (1) read an event, (2)
>> process it, and (3) read another event, you may have missed new
>> events that occurred while you were processing the old one.
>>
>> But maybe that isn't such a big deal (humans cannot generate
>> key-presses fast enough to cause events to be missed).
>
> Ah! That's it! What a luck that someone found this one that drove me
> completely crazy already! Humans might not generate key events fast
> enough, but mouse events are lost /regularly./ It happens often enough
> that the mouse cursor ends up over a window that is not focused after
> moving the mouse. OMG please fix :O

Okay, I see two options here.

1. Minimize the amount of time spent on processing an event, so that
you reduce the likelihood of missing an event while processing an
old one.

Practically, this would require something like a two-stage fetch.
The first stage is a thread which _only_ receives an event and
passes it down to the next stage. The second stage will do
processing of the event.

Again, this is not 100% perfect; the first stage can still miss
events when passing an old event down to the second stage.

2. Use a _bus_ communication channel, which is separate from the
usual IXP stuff, for broadcasting events. This way, anyone
interested in events can simply connect to this bus and get events
at their leisure, without any data loss (the bus listener would be
buffered I/O, like a socket, so you do not miss any events).

The reason I suggest that this is separate from IXP stuff is because
IXP seems to be purely a datagram oriented service, rather than a
connection oriented service. You request for a file read, and you
get a response with the file's entire contents. There doesn't seem
to be a concept of streaming, which is needed for special cases like
/event.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFFEZo/mV9O7RYnKMcRAo/zAJ9v55Q0wXljAiB6Py13S9zWPuHhPwCfTGiv
s0/jul9dD/MM2YbdWLiGt5M=
=VTYH
-----END PGP SIGNATURE-----
Received on Wed Sep 20 2006 - 21:45:22 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:14:17 UTC