Re: [PATCH] /dev/epoll update ...

[Christopher K. St. John]

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 [e-mail]
DistribuTopia http://www.distributopia.com