Messages in this thread |  | | Date | Fri, 21 Sep 2001 09:48:13 -0700 (PDT) | From | Davide Libenzi <> | Subject | Re: [PATCH] /dev/epoll update ... |
| |
On 21-Sep-2001 Ton Hospel wrote: > In article <XFMail.20010919151147.davidel@xmailserver.org>, > Davide Libenzi <davidel@xmailserver.org> writes: >> On 19-Sep-2001 Christopher K. St. John wrote: >>> Davide Libenzi wrote: >> Again : >> >> 1) select()/poll(); >> 2) recv()/send(); >> >> vs : >> >> 1) if (recv()/send() == FAIL) >> 2) ioctl(EP_POLL); >> > > mm, I don't really get the second one. What if the scenario is: > In the place you are in your program, you now decide that a > read is in order. You try read, nothing there yet, > the syscall returns, the data event happens and THEN you go into > the ioctl ? > > Possibilities seem: > 1) You hang, having missed the only event that will happen > 2) Just having data triggers the ioctl (maybe only the first time), > why not leaving out the initial read then and just do it afterwards > like select ? > 3) It generates a fake event the first time you notify interest, but then > the startup case leads to doing the read uselessly twice. > > Or is there a fourth way I'm missing this really works ?
That was a simplified function :
while (recv()/send() == FAIL) ioctl(EP_POLL);
this is the right code. If an event happens between the recv() and the ioctl() this is cached by the driver and it'll be returned from ioctl().
- 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/
|  |