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

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

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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFFEsq1mV9O7RYnKMcRAmtAAKCrwaBeK9AgkjSbcnLuL+P3KIjk8gCeONWa
Copgp/kULHnQUt741x9R+UI=
=VcWL
-----END PGP SIGNATURE-----
Received on Thu Sep 21 2006 - 19:25:12 UTC