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