For the convenience I'll answer to Nick's questions from
SF's patch tracker in this list.
> A few initial questions:
> - How exactly does the test_et.c file test the edge-triggered behavior?
> As near as I can tell, the test ought to pass whether EV_ET works or not.
> What am I missing?
I hardly find a direct and automatic way to do it...
Try following patch for test_et.c
--- test_et2.c 2008-05-29 21:53:15.000000000 +0200
+++ test_et.c 2008-05-29 21:50:42.000000000 +0200
@@ -27,28 +27,27 @@
#include <evutil.h>
int test_okay = 1;
-int called = 0;
+int edge_triggered = 0;
static void
read_cb(int fd, short event, void *arg)
{
- char buf[256];
+ char buf;
int len;
- do{
- len = read(fd, buf, sizeof(buf));
+ len = read(fd, &buf, sizeof(buf));
- printf("%s: %s %d%s\n", __func__, event & EV_ET ? "etread"
: "read",
- len, len ? "" : " - means EOF");
+ printf("%s: %s %d%s\n", __func__, event & EV_ET ? "etread" : "read",
+ len, len ? "" : " - means EOF");
- if (!len) {
- if (called > 0)
- test_okay = 0;
- event_del(arg);
- }
+ if(event & EV_ET)
+ edge_triggered++;
- called++;
- }while(len != 0);
+ if (!len) {
+ if (edge_triggered > 0)
+ test_okay = 0;
+ event_del(arg);
+ }
}
#ifndef SHUT_WR
You should get following now:
$ ./test_et
read_cb: etread 1
^C *HANGING!!!*
$ EVENT_NOKQUEUE=1 EVENT_NOEPOLL=1 ./test_et
read_cb: read 1
read_cb: read 1
read_cb: read 1
read_cb: read 1
read_cb: read 1
read_cb: read 1
read_cb: read 1
read_cb: read 1
read_cb: read 1
read_cb: read 1
read_cb: read 1
read_cb: read 1
read_cb: read 0 - means EOF
Means with ET the handler is being invoked only once when amount of data
available overcame threshold of 0.
I must think a bit how to automate this. Please give me time.
> - Is it really a good idea to have backends that do not support EV_ET
> silently ignore it?
> If writers are really hoping for edge-triggered behavior, won't they
> be surprised when they
> sometimes get it, and sometimes don't?
Yes and no. Principally there could be a situation where application will
change it's behaviour depending of the awareness of ET, e.g. set a
particular event handler in event_set, providing two different
optimized hardcoded handlers for each case. Then it would be better
to go back to a solution from Adam Langley where ET capability is
explicitly specified for each multiplexing method:
https://webmail.iro.umontreal.ca/pipermail/gambit-list/2005-August/000367.html
On the other hand it is sometimes very comfortable to simple check
presence of EV_ET flag, whenever a difference between ET and non-ET
implementation costs only few lines (Perl way).
I think that both ways are worth them, so we could adsorb all of them.
--
Best regards,
Valery Kholodkov
_______________________________________________
Libevent-users mailing list
[email protected]
http://monkeymail.org/mailman/listinfo/libevent-users
