Hi Scott,
the best way for fixing anything that looks like a bug is to write a
test case that triggers the desired behavior. I have to admit that I
implemented the watermark code with a special use case in mind that
unfortunately did not materialize. That means it's not well tested.
Given that you seem to be working with the code, I would suggest that
you write the test case and then we can look at it and see what the
right semantics should be.
The current code stops reading and callbacks once the high watermark
has been reached. Once you start draining the input buffer, reading
continues. I can see that there is a case where one might reach the
high watermark is one go and never notify the user. That seems
problematic to me, but is easy to fix.
Niels.
On 4/8/07, Scott Kevill <[EMAIL PROTECTED]> wrote:
I've just started working with libevent as of v1.3b, and it appears
to still have a bug with high watermarks for bufferevents. Chris
Maxwell discovered and mentioned this on the list just over a year ago:
http://monkeymail.org/archives/libevent-users/2006-February/
000101.html
His solution had not been implemented in any subsequent releases of
libevent, and the bug remains.
Although his solution (removing the return in the high-watermark
check) does work in preventing lost callbacks, I don't think it is
the best solution (something he also wondered). The callback can
still be called with more data buffered than the highwater mark.
Exactly how much more depends on the arbitrary decisions made in
evbuffer_read.
The simple change I made to fix the problem was changing:
if (bufev->wm_read.high != 0)
howmuch = bufev->wm_read.high;
to:
if (bufev->wm_read.high != 0)
howmuch = bufev->wm_read.high - EVBUFFER_LENGTH(bufev->input);
The original problem was that it was using the high watermark as the
max *additional* bytes to read, instead of the max *total* bytes post-
read.
It might depend on your idea of what the high watermark behaviour
should be (it's not really documented), but to me this makes more
sense as the caller decides how much buffering should be done.
While the above change works for my needs, it's not complete either,
as there are situations where howmuch will go zero or negative. (eg.
Not draining the entire buffer in the read-callback). I haven't dug
deeper to figure out the best thing to do in this case, but the
socket read should be skipped since there's already more buffered
than the high watermark. The next read-callback would be with
EVBUFFER_LENGTH(bufev->input) > bufev->wm_read.high, but if you're
not completely draining the buffer in the callback, then you should
probably expect that.
Comments?
Scott.
--
Scott Kevill
GameRanger Technologies
http://www.GameRanger.com
multiplayer online gaming services
_______________________________________________
Libevent-users mailing list
[email protected]
http://monkey.org/mailman/listinfo/libevent-users
_______________________________________________
Libevent-users mailing list
[email protected]
http://monkey.org/mailman/listinfo/libevent-users
