Messages in this thread |  | | Date | Wed, 19 Sep 2001 14:03:19 -0500 | From | "Christopher K. St. John" <> | Subject | Re: [PATCH] /dev/epoll update ... |
| |
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/
|  |