lkml.org 
[lkml]   [1999]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: > 15,000 Simultaneous Connections
Chuck Lever wrote:

> On Tue, 7 Sep 1999, Rogier Wolff wrote:
> > I would then prefer to go with the API that the digital guys suggested
> > in: http://www.cs.rice.edu/~gaurav/papers/usenix99.ps
> >
> > #define EVENT_READ 0x01
> > #define EVENT_WRITE 0x02
> > #define EVENT_EXCEPT 0x03
> >
> > typedef struct {
> > int fd;
> > unsigned mask;
> > } event_descr_t;
> >
> > int declare_interest (int fd, int interestmask, int *statemask);
> > int get_next_event (int array_max, event_descr_t *ev_array, struct timeval *timeout);
> >
> > If you want, you can then simulate select in the library.
> >
> > int select(int n, fd_set *readfds, fd_set *writefds,
> > fd_set *exceptfds, struct timeval *timeout)
> > {
> >
> > It should just pass on the call to the system call for small nmax.
> >
> > if (n < 256)
> > return sys_select (n, readfds, writefds, exceptfds, timeout);
> >
> > When nmax goes above a certain threshold, it will become viable to
> > compare an old cached version of the arrays to the current one,
> > register the differences with declare_interest, and then empty the
> > event queue. (For the example, I'll work bit_wise, but the actual
> > implementation will work with a long at a time.)
>
> as much as i like gaurav's model, there are still some interesting issues
> to be worked out.
>
> there doesn't appear to be a way to create more than one event queue per
> process. for instance, you *can* emulate select() in the C library with
> the new API, but what if the application also wants to use the new API?
> what happens when the select() emulator picks up an event that was
> destined for a different event handler? can it push the event back onto
> the event queue?
>
> - Chuck Lever

I too think Gaurav's has the right approach for most uses. It seems pretty straightforward
to add a "queue create" call, and an extra queue identifier parameter to the other calls.
Probably a "queue delete" would be needed to round things out. With that addition I think
the design should suit nearly everyone. The multi-queue addition seems worthwhile. Only a
small percentage of programs need this, but it should not cause a significant hit to the
others, so its a Good Thing.

I don't see why you would want to emulate the select call through the new API. You can't
really get rid of the existing select call - it would break too many programs. If both the
select and event queue mechanisms are handled in the kernel it doesn't seem like an event
queue push would be necessary.

The scalability web site refers to a "hinting" feature that is in progress, but the
description is not very detailed. Is this, in fact, an implementation of Gaurav's design?

Steve



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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