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