Re: > 15,000 Simultaneous Connections

Joerg Pommnitz (pommnitz@darmstadt.gmd.de)
Wed, 08 Sep 1999 08:47:13 +0200

R.E.Wolff@BitWizard.nl (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);

One of the major drawbacks (besides the scalability issues discussed
here) of
select is the missing integration of other kernel generated events. It
would be
really nice if the select replacement could synchronously wait for
signals and
maybe SYSV-IPC. If it could wait for signals the libc implementation
might be able
to wait for pthread conditions, too.
What I want to say is, that I want to be able to wait for just about any
event.
This way single threaded applications would be much easier to write.

This would mean a change to declare_interest so that it can accept
parameters
other than a file descriptor and to the event_descr_t so that it can
report
events other than those related to a file descriptor.

Regards
Joerg

-
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/