Messages in this thread | | | Date | Wed, 08 Sep 1999 07:12:03 +0000 | From | Steve Underwood <> | Subject | Re: > 15,000 Simultaneous Connections |
| |
Joerg Pommnitz wrote:
> 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.
This is a _very_ valid point. I never use the SYSV-IPC, simply because they will not fit into a select/poll framework. A more comprehensive "tell me when something is ready" would really open up the use of these features.
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/
| |