[lkml]   [2001]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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):
- 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):
- 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:03    [W:0.097 / U:1.852 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site