On 2/3/14, Clemens Ladisch <clemens@xxxxxxxxxx> wrote: > Nathaniel Yazdani wrote: >> Using the normal I/O interface to manipulate eventpolls is much neater >> than using epoll-specific syscalls > > But it introduces a _second_ API, which is epoll-specific too, and does > not use the standard semantics either. > >> while also allowing for greater flexibility (theoretically, pipes could >> be used to filter access). > > I do not understand this. The idea here was that if epoll is controlled by read()/write(), then a program could be written so that it expects the epoll to dup()ed to a second file descriptor, using one exclusively for writing & the other exclusively for reading. That way, if an application is in debug mode, for example, it could start up a thread to replace those two file descriptors with pipes, so that thread would then be able to tee, preprocess, or do whatever else to the epoll streams. >> read() simply waits for enough events to fill the provided buffer. > > The usual semantics of read() are to return a partially filled buffer if > it would block otherwise, i.e., blocking is done only if the returned > buffer would have been empty. > >> As timeout control is essential for polling to be practical, ioctl() is >> used to configure an optional timeout > > This is what the timeout parameter of poll() and friends is for. I admit that part of this approach isn't the best. Either way I appreciate your feedback, Nathaniel Yazdani -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
