Messages in this thread |  | 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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |