Messages in this thread | | | Date | Wed, 08 Sep 1999 08:47:13 +0200 | From | Joerg Pommnitz <> | Subject | Re: > 15,000 Simultaneous Connections |
| |
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/
| |