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

On Wed, Sep 20, 2006 at 02:24:53AM -0700, Suraj N. Kurapati wrote:
>
>wmii-4 simply returns the next event and closes the read request.
>
>wmii-3.1 returns the next event, closes the read request, and
>continues to send new events as they occur (even though the request
>was already closed).
>
>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.

I know that this thread is ancient, but you have this all wrong.

wmii-3 exhibits much strange behavior with relation to reads on /event,
mainly related to the fact that it keeps a 'pending' member for each
connection structure, and broadcasts Rreads with the given tag for each
event broadcast if the member is set. It doesn't wait for a new Tread to
broadcast, if the member is set. It also doesn't unset the member once a
read has completed. This causes many types of strange behavior,
especially on clients such as Inferno and v9fs, where /event can only be
opened once and behave properly.

wmii-4, however, buffers new events in a separate buffer for each open
Fid on /event. When an Tread comes in for one of these Fids, it writes
as much of the buffer as the clients have requested. Therefore, no
events are lost, and there are no erratic Rreads sent.

-- 
Kris Maglione
Working capital doesn't.