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

On Thu, Sep 21, 2006 at 10:24:05AM -0700, Suraj N. Kurapati wrote:
> Anselm R. Garbe wrote:
> > Sorry guys, but I think you are completely wrong.
> >
> > 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).
> >
> > NO no no. The behavior of reading /event in wmii-3 and
> > wmii-current is equal. Reading /event means reading a file which
> > never ends, thus the read is blocking until a new event occures.
> > I think you misunderstand the code, though it's true that my
> > wmii-3.x fs.c implementation is a nightmare. Kris' wmii-4 fs.c
> > implementation is much better in many decisions. However, on the
> > 9P level there is no difference!!!!
>
> Okay, having no difference at 9P level is the desired behavior.
> However, wmii-3.1 has a bug which makes it send new events even
> after the connection has terminated. For example, consider that
> /event is read two times:
>
> 1. Twalk is sent for /event
>
> 2. Rwalk is received
>
> 3. Topen is sent with fid
>
> 4. Ropen is received with fid
>
> # /event file is now opened and ready for reading
>
> # round one
>
> 5. Tread is sent
>
> 6. Rread is received
>
> # round two
>
> 7. Tread is sent
>
> 8. Rread is received
>
> 9. Tclunk is sent with fid
>
> 10. Rclunk is received with fid
>
> # /event file is closed for reading
>
> 11. In wmii-3.1, Rerror is now received. It says "file not found",
> and has the same tag as that of most recent Tread! This is because
> wmii-3.1 was actually trying to send an Rread but discovered that
> the fid had already been clunked, so instead it sends an Rerror.
>
>
> Try this in wmii-4, and you will see that there is no bogus 11th
> fcall sent by wmii. This is why wmii-3.1 freezes after lots of 9P
> traffic.
>
> The patch I submitted makes sure that the Tread + Rread cycle is
> atomic. That is, we must not have stuff like Tread + Rread + Rread +
> ... + Rread. Instead, we must have stuff like (Tread + Rread) +
> (Tread + Rread) + ... + (Tread + Rread).
>
> >> 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.
> >
> > Sorry, this is not true. No events are lost. Maybe there is a
> > bug somewhere else, but
>
> I disagree. Suppose an IXP client does one Tread + Rread cycle,
> sleeps for three minutes, and does another Tread + Rread cycle. The
> events that occurred during those three minutes are lost (to this
> particular client).
>
> > events are send to all connections which have opened /event.
>
> True, but this (Rread) should only be sent in response to Tread.

Sorry, I was wrong, that is exactly the bug, though the event
loss is more a side-effect in a special case than regular
behavior (at least for the main event loop in wmiirc).

This should be fixed indeed.

-- 
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361