Linus Torvalds wrote:
> Basically, the main loop would boil down to
>
> for (;;) {
> static struct event ev_list[MAXEV];
> get_event(ev_list, MAXEV, &tmout);
> .. timeout handling here ..
> }
>
> because get_even() would end up doing all the user-mode calls too (so
> "get_event()" is no longer a system call: it's a system call + a for-loop
> to call all the ID handler functions that were associated with the events
> that triggered).
>
> So the "struct event" would just be:
>
> struct event {
> int fd;
> unsigned long mask;
> void *opaque;
> void (*event_fn)(ind fd, unsigned long mask, void *opaque);
> }
>
> and there's no need for separate event queues, because the separate event
> queues have been completely subsumed by the fact that every single event
> has a separate event function.
OK, guess I buy the one-queue-to-bind-them-all argument.
Might be good to pick more unique names than 'struct event' and 'get_event'.
People probably use those already.
Hiding ev_list is probably ok. However,
http://www.citi.umich.edu/techreports/reports/citi-tr-00-7.pdf
suggests that knowing how many events are pending is a useful measure
of server load, and that if more than a certain number of events
are pending, web servers should reject new connections. Thus it might
be handy to make the return value of get_event be the number of events
gotten.
> So now you'd start everything off (assuming the same kind of "listen to
> everything and react to it" server as in my previous example) by just
> setting
>
> bind_event(sock, POLLIN, NULL, accept_fn);
A couple questions:
* how do you unbind? (By calling bind_event with NULL as the accept_fn?)
* how do you change a mask? (By calling bind_event with a new mask?)
* Is it ok to do these things while in an event_fn? (Yes?)
* Do you get an event whenever an fd is ready for something, or
only when its readiness changes? (Presumably whenever an fd is ready for something?)
> (This is also the ideal event programming interface - signals get racy and
> hard to handle, while in the above example you can trivially just be
> single-threaded. Which doesn't mean that you CANNOT be multi-threaded if
> you want to: you multi-thread things by just having multiple threads that
> all call "get_event()" on their own).
I for one will be glad to not have to think of the races
caused by the delay between signal queueing and signal pickup.
- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
