-----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----- _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
