Messages in this thread |  | | Date | Wed, 19 Sep 2001 12:30:29 -0700 (PDT) | From | Davide Libenzi <> | Subject | Re: [PATCH] /dev/epoll update ... |
| |
On 19-Sep-2001 Christopher K. St. John wrote: > 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.
No it does't check. It's not needed for how it works.
> // 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)
select()/poll() works in a different way :
1) select()/poll(); 2) recv()/send();
while /dev/epoll works like described above :
1) if (recv()/send() == FAIL) 2) wait_event();
I intentionally changed the name to epoll coz it works in a different way.
- Davide
- 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/
|  |