Re: [Libevent-users] strange bufferevent_new interface
You can control when you read and write with bufferevents. There is an enable function that takes care of that. I have used them for streaming protocols that had some lock step requirements. Niels. On 7/27/06, William Ahern <[EMAIL PROTECTED]> wrote: On Thu, Jul 27, 2006 at 09:27:09PM +0200, Rainer Giedat wrote: > Hi, > > while reading some code which used buffered events, i saw that > you really have to define callbacks for read, write and error, > even if you do not care about one of them. > Is there a reason for that? > > This ends up in ugly code, defining empty functions as callbacks. > The problem is, that bufferevent_new enables EV_WRITE and > EV_READ regardless of beeing defined not NULL. (On OpenBSD only > EV_WRITE currently) > > If there is no reason for that, i would suggest to apply the > following diff. It fixes the problem for me. :) > > Thanks for the great work Niels. > So long... Well, w/o this behavior it might be impossible to integrate this w/ OpenSSL. Just to complete a read through an SSL/TLS stream, you may need to first complete a write (for instance, when re-keying or other protocol management work) which can actually occur quite often. I never figured out how to make this work cleanly w/ libevent's buffered I/O API. Maybe it's just not possible, period, so it doesn't matter. - Bill ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] strange bufferevent_new interface
On Thu, Jul 27, 2006 at 09:27:09PM +0200, Rainer Giedat wrote: > Hi, > > while reading some code which used buffered events, i saw that > you really have to define callbacks for read, write and error, > even if you do not care about one of them. > Is there a reason for that? > > This ends up in ugly code, defining empty functions as callbacks. > The problem is, that bufferevent_new enables EV_WRITE and > EV_READ regardless of beeing defined not NULL. (On OpenBSD only > EV_WRITE currently) > > If there is no reason for that, i would suggest to apply the > following diff. It fixes the problem for me. :) > > Thanks for the great work Niels. > So long... Well, w/o this behavior it might be impossible to integrate this w/ OpenSSL. Just to complete a read through an SSL/TLS stream, you may need to first complete a write (for instance, when re-keying or other protocol management work) which can actually occur quite often. I never figured out how to make this work cleanly w/ libevent's buffered I/O API. Maybe it's just not possible, period, so it doesn't matter. - Bill ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] strange bufferevent_new interface
Have a look at the code that is in CVS. At the moment, only EV_WRITE is enabled by default. I have to think about the implications of NULL callbacks. Thanks for the patch. Niels. On 7/27/06, Rainer Giedat <[EMAIL PROTECTED]> wrote: Hi, while reading some code which used buffered events, i saw that you really have to define callbacks for read, write and error, even if you do not care about one of them. Is there a reason for that? This ends up in ugly code, defining empty functions as callbacks. The problem is, that bufferevent_new enables EV_WRITE and EV_READ regardless of beeing defined not NULL. (On OpenBSD only EV_WRITE currently) If there is no reason for that, i would suggest to apply the following diff. It fixes the problem for me. :) Thanks for the great work Niels. So long... /dev/rainer ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
[Libevent-users] strange bufferevent_new interface
Hi,
while reading some code which used buffered events, i saw that
you really have to define callbacks for read, write and error,
even if you do not care about one of them.
Is there a reason for that?
This ends up in ugly code, defining empty functions as callbacks.
The problem is, that bufferevent_new enables EV_WRITE and
EV_READ regardless of beeing defined not NULL. (On OpenBSD only
EV_WRITE currently)
If there is no reason for that, i would suggest to apply the
following diff. It fixes the problem for me. :)
Thanks for the great work Niels.
So long...
/dev/rainer
--- evbuffer.c 2005-04-20 00:55:45.0 +0200
+++ ../evbuffer.c 2006-07-27 20:59:44.0 +0200
@@ -136,7 +136,8 @@
return;
error:
- (*bufev->errorcb)(bufev, what, bufev->cbarg);
+ if (*bufev->errorcb != NULL)
+ (*bufev->errorcb)(bufev, what, bufev->cbarg);
}
static void
@@ -186,7 +187,8 @@
return;
error:
- (*bufev->errorcb)(bufev, what, bufev->cbarg);
+ if (*bufev->errorcb != NULL)
+ (*bufev->errorcb)(bufev, what, bufev->cbarg);
}
/*
@@ -217,8 +219,15 @@
return (NULL);
}
- event_set(&bufev->ev_read, fd, EV_READ, bufferevent_readcb, bufev);
- event_set(&bufev->ev_write, fd, EV_WRITE, bufferevent_writecb, bufev);
+ if (readcb != NULL) {
+ event_set(&bufev->ev_read, fd, EV_READ, bufferevent_readcb,
bufev);
+ bufev->enabled = EV_READ;
+ }
+
+ if (writecb != NULL) {
+ event_set(&bufev->ev_write, fd, EV_WRITE, bufferevent_writecb,
bufev);
+ bufev->enabled = EV_WRITE;
+ }
bufev->readcb = readcb;
bufev->writecb = writecb;
@@ -226,8 +235,6 @@
bufev->cbarg = cbarg;
- bufev->enabled = EV_READ | EV_WRITE;
-
return (bufev);
}
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
