Davide Libenzi wrote:
>
> > /dev/epoll only gives you events on state changes. So,
> > for example, if you accept() a new socket and add it to the
> > interest list, you (probably) won't get a POLLIN. That's
> > not fatal, but it's awkward.
>
> Being an event change notification you simply can't add the fd
> to the "monitor" after you've issued the accept().
> The skeleton for /dev/epoll usage is :
>
> while (system_call(...) == FAIL) {
>
> wait_event();
> }
>
I'm not sure I understand. I'm assuming you can do
something along the lines of:
// application accepts new socket
new_socket_fd = accept()
// application registers interest with epoll
write(dev_poll_fd, new_socket_fd):
drivers/char/eventpoll.c:ep_insert():
- add new_socket_fd to interest list
- check new_socket_fd for readable, writable, and
error. if any true, then add new event to
event queue, as if the state had changed.
// application asks for current set of events
app: ioctl(dev_poll_fd, EP_POLL):
drivers/char/eventpoll.c:ep_poll():
- return the current event queue
In other words, when new fd's are added to the
interest set, you generate synthetic events which
are returned at the next ioctl(EP_POLL).
Are you saying that isn't possible? It's the
suggested behavior from the BMD paper, so evidently
they got it to work somehow (and I suspect it's how
Solaris /dev/poll works, but I'm not sure)
-- Christopher St. John cks@distributopia.com DistribuTopia http://www.distributopia.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Sep 23 2001 - 21:00:32 EST