lkml.org 
[lkml]   [2000]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
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/

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:0.105 / U:1.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site