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

On Wed, 20 Sep 2006 12:45:04 -0700
"Suraj N. Kurapati" <skurapat_AT_ucsc.edu> wrote:

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

What about making /event a directory and having a separate event file
for each listening process. When you do a read on /event/ctl, a new
event file is created and its unique name is returned. Then you would
have simple blocking I/O for as many listeners as you want.

On the other hand, one could simply drop the possibility for multiple
clients to get events at the same time. Then only wmiirc would be able
to get events, and other scripts should rely on wmiirc to get their
events.

Greetings,
Denis