From: bert h. <ah...@ds...> - 2002-10-29 00:40:40
|
On Mon, Oct 28, 2002 at 04:32:50PM -0800, Davide Libenzi wrote: > The code above it's just fine. The "fd" is not lost because the falling > through : > > do_use_fd(fd); > > will make good use of it. If that code dares to read immediatly from the fd without having an explicit POLLIN event, which also means that epoll can only be used in this fashion with nonblocking sockets. The listening socket needs to do that anyhow as the connection may have vanished anyhow - select has that problem too. To trigger the problem, see the following very nasty 'exploit'. Telnet to port 10000 and immediately enter a line of text and press enter. This line might very well be 'GET / HTTP/1.0'. Because of the inserted sleep(2); below, this line will never be reported by sys_epoll_wait() in its current form. To see it appear, enter an additional line after a while. So either fix up sys_epoll_ctl() to insert an edge if there is data at insertion time (which needs some locking probably to get it right), OR document the interface that it should only be used with non-blocking sockets and that the caller should immediately try to read after the initial sys_epoll_ctl insert call. This last solution sounds very bad and confusing. Code: #include <stdio.h> #include <errno.h> #include <asm/page.h> #include <asm/poll.h> #include <linux/linkage.h> #include <linux/eventpoll.h> #include <linux/unistd.h> #include <netinet/in.h> #include <string.h> #include <sys/socket.h> #include <sys/types.h> #include <stdlib.h> #include <unistd.h> #define __sys_epoll_create(maxfds) _syscall1(int, sys_epoll_create, int, maxfds) #define __sys_epoll_ctl(epfd, op, fd, events) _syscall4(int, sys_epoll_ctl, \ int, epfd, int, op, int, fd, unsigned int, events) #define __sys_epoll_wait(epfd, events, timeout) _syscall3(int, sys_epoll_wait, \ int, epfd, struct pollfd const **, events, int, timeout) __sys_epoll_create(maxfds) __sys_epoll_ctl(epfd, op, fd, events) __sys_epoll_wait(epfd, events, timeout) // asmlinkage int sys_epoll_wait(int epfd, struct pollfd const **events, int timeout); int main() { int kdpfd; struct pollfd const *pfds; int nfds; int timeout=2; struct sockaddr_in local; socklen_t addrlen; int s, client; int n; char line[80]; int ret; if ((kdpfd = sys_epoll_create(10)) < 0) { perror("sys_epoll_create"); return -1; } s=socket(AF_INET,SOCK_STREAM,0); memset(&local,0,sizeof(local)); local.sin_family=AF_INET; local.sin_addr.s_addr = INADDR_ANY; int tmp=1; if(setsockopt(s,SOL_SOCKET,SO_REUSEADDR,(char*)&tmp,sizeof tmp)<0) { perror("setsockopt"); return 0; } local.sin_port=htons(10000); if(bind(s, (struct sockaddr*)&local,sizeof(local))<0) { perror("bind"); return 0; } if(listen(s,128)<0) { perror("listen"); return 0; } if (sys_epoll_ctl(kdpfd, EP_CTL_ADD, s, POLLIN ) < 0) { fprintf(stderr, "sys_epoll set insertion error: fd=%d\n", s); return -1; } addrlen=sizeof(local); for(;;) { nfds = sys_epoll_wait(kdpfd, &pfds, -1); fprintf(stderr,"sys_epoll_wait returned: %d\n",nfds); for(n=0;n<nfds;++n) { if(pfds[n].fd==s) { client=accept(s, (struct sockaddr*)&local, &addrlen); sleep(2); if(client<0){ perror("accept"); continue; } if (sys_epoll_ctl(kdpfd, EP_CTL_ADD, client, POLLIN ) < 0) { fprintf(stderr, "sys_epoll set insertion error: fd=%d\n", client); return -1; } } else { if((ret=read(pfds[n].fd,line,79))>0) printf("read from fd %d: '%.*s'\n", pfds[n].fd, ret>2 ? ret-2 : 0,line); } } } return 0; } > > > > - Davide > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to maj...@vg... > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO |
From: Davide L. <da...@xm...> - 2002-10-29 00:47:58
|
On Tue, 29 Oct 2002, bert hubert wrote: > If that code dares to read immediatly from the fd without having an explicit > POLLIN event, which also means that epoll can only be used in this fashion > with nonblocking sockets. The epoll interface has to be used with non-blocking fds. The EAGAIN return code from read/write tells you that you can go safely to wait for events for that fd because you making the read/write to return EAGAIN, you consumed the whole I/O space for that fd. Consuming the whole I/O space meant that you brought the signal to zero ( talking in ee terms ), and a followinf 0->1 transaction will trigger the event. Where 1 means I/O space available ... - Davide |
From: bert h. <ah...@ds...> - 2002-10-29 00:53:37
|
On Mon, Oct 28, 2002 at 04:57:12PM -0800, Davide Libenzi wrote: > > If that code dares to read immediatly from the fd without having an explicit > > POLLIN event, which also means that epoll can only be used in this fashion > > with nonblocking sockets. > > The epoll interface has to be used with non-blocking fds. The EAGAIN Ok, so that is two things that need to be in the manpage and probably in bold: 1) epoll only works on pipes and sockets (not on tty, not on files) 2) epoll must be used on non-blocking sockets only (and describe the race that happens otherwise) If you send me the source of your manpages I'll work it in if you want. I still vote for checking at insert time however unless that is too expensive. Yes, we want people to read the manpages and heed them, but we also not want to create interfaces that are needlessly errorprone. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO |
From: Davide L. <da...@xm...> - 2002-10-29 01:04:30
|
On Tue, 29 Oct 2002, bert hubert wrote: > Ok, so that is two things that need to be in the manpage and probably in > bold: > > 1) epoll only works on pipes and sockets > (not on tty, not on files) > > 2) epoll must be used on non-blocking sockets only > (and describe the race that happens otherwise) > > If you send me the source of your manpages I'll work it in if you want. No problem ... > I still vote for checking at insert time however unless that is too > expensive. Yes, we want people to read the manpages and heed them, but we > also not want to create interfaces that are needlessly errorprone. This will make the API to be really error prone by giving the user the impression that he can go sleeping for a given fd each time he wants. The rule "you can wait for events only after you received EAGAIN" looks like a very short and precise rule. On the contrary of "you can go wait for events after you received EAGAIN or after accept/connect". And the fact on using the fd immediately after an accept/connect is enforced by two very likely facts : 1) on accept() it's very likely that the first packet brough you something more than SYN 2) on connect() you have the full I/O write space available - Davide |
From: Hanna L. <ha...@us...> - 2002-10-29 01:14:32
|
--On Monday, October 28, 2002 17:13:53 -0800 Davide Libenzi <da...@xm...> wrote: > On Tue, 29 Oct 2002, bert hubert wrote: > >> Ok, so that is two things that need to be in the manpage and probably in >> bold: >> >> 1) epoll only works on pipes and sockets >> (not on tty, not on files) >> >> 2) epoll must be used on non-blocking sockets only >> (and describe the race that happens otherwise) >> >> If you send me the source of your manpages I'll work it in if you want. > > No problem ... > If you need any help with the Man pages I will be glad to help too. It looks like providing examples of how to use it would be very useful since this is something application writers are supposed to use... > events after you received EAGAIN or after accept/connect". And the fact on > using the fd immediately after an accept/connect is enforced by two very > likely facts : > > 1) on accept() it's very likely that the first packet brough you something > more than SYN > > 2) on connect() you have the full I/O write space available Do you think these should be mentioned explicitly? Thanks a lot. Hanna |
From: Davide L. <da...@xm...> - 2002-10-29 01:30:02
|
On Mon, 28 Oct 2002, Hanna Linder wrote: > If you need any help with the Man pages I will be glad to > help too. It looks like providing examples of how to use it would be > very useful since this is something application writers are supposed > to use... IMHO I find the ephttpd.c, once stripped of the tons of #ifdef to handle the other interfaces, to be a very clear example about how to use the API togheter with coroutines. Using it with an event driven state machine would require a little bit more code, but nothing brutal ... Anyway yes, the NOTES section of the man pages should be "enriched" with a few notes and maybe code samples. - Davide |
From: Jamie L. <lk...@ta...> - 2002-10-29 02:05:56
|
bert hubert wrote: > 1) epoll only works on pipes and sockets > (not on tty, not on files) fifos come to mind as the other things which are a bit like pipes/sockets. > > 2) epoll must be used on non-blocking sockets only > (and describe the race that happens otherwise) That much is implied simply by epoll being a queue of not_ready->ready edge transitions. It would be good for the manual to explain this, but it is clearly implied by the API if you think about it. -- Jamie |
From: Davide L. <da...@xm...> - 2002-10-29 02:35:26
|
On Tue, 29 Oct 2002, Jamie Lokier wrote: > > > > 2) epoll must be used on non-blocking sockets only > > (and describe the race that happens otherwise) > > That much is implied simply by epoll being a queue of not_ready->ready > edge transitions. It would be good for the manual to explain this, > but it is clearly implied by the API if you think about it. Bert and Hanna are working on man pages right now with the aim of adding those notes ... - Davide |
From: Hanna L. <ha...@us...> - 2002-10-29 04:07:04
|
--On Monday, October 28, 2002 18:44:50 -0800 Davide Libenzi wrote: > Bert and Hanna are working on man pages right now with the aim of adding > those notes ... The source for the man pages is included and the viewable versions are on Davide's web site here: http://www.xmailserver.org/linux-patches/epoll.txt http://www.xmailserver.org/linux-patches/epoll_create.txt http://www.xmailserver.org/linux-patches/epoll_ctl.txt http://www.xmailserver.org/linux-patches/epoll_wait.txt They describe how to use epoll, under what circumstances it will be best used or not to use it and other man page tidbits. Also note there is an updated version of sys_epoll with the latest input received from the mailing lists. That is attached as well (for easy merging) ;) Bert and Davide did all the work. I just did a little cleanup. Please include the man pages if^H^Hwhen you take the patches. Thanks. Hanna |
From: Andrew M. <ak...@di...> - 2002-10-29 05:10:07
|
Hanna Linder wrote: > > sys_epoll-2.5.44-last.diff Folks, when I took a 15-minute look at this code last week I found several bugs, some of which were grave. It's a terrible thing to say, but a sensible person would expect that a closer inspection would turn up more problems. Now, adding bugs to existing code is fine and traditional - people find them quickly and they get fixed up. But for *new* code, problems will take months to discover. The only practical way to get this code vetted for inclusion is a close review. And that is a sizeable task. The core implementation file is 1,600 lines. And I wonder how many people have counted the number of comments in there? Well, I'll make it easy: zero. Nil. Nada. (Well, OK, a copyright header, and something which got cut-n-pasted from inode.c) In my wildly unconventional opinion this alone makes epoll just a hack, of insufficient quality for inclusion in Linux. We *have* to stop doing this to ourselves! epoll seems to be a good and desirable thing. To move forward I believe we need to get this code reviewed, and documented. I can do that if you like; it will take me several weeks to get onto it. But until that is completed I would oppose inclusion of this code. |
From: Randy.Dunlap <rdd...@os...> - 2002-10-29 05:31:53
|
On Mon, 28 Oct 2002, Andrew Morton wrote: | Hanna Linder wrote: | > | > sys_epoll-2.5.44-last.diff | | Folks, | | when I took a 15-minute look at this code last week I found several | bugs, some of which were grave. It's a terrible thing to say, but | a sensible person would expect that a closer inspection would turn | up more problems. | | Now, adding bugs to existing code is fine and traditional - people | find them quickly and they get fixed up. | | But for *new* code, problems will take months to discover. The only | practical way to get this code vetted for inclusion is a close review. | | And that is a sizeable task. The core implementation file is | 1,600 lines. And I wonder how many people have counted the | number of comments in there? | | Well, I'll make it easy: zero. Nil. Nada. | | (Well, OK, a copyright header, and something which got cut-n-pasted | from inode.c) | | In my wildly unconventional opinion this alone makes epoll just a hack, | of insufficient quality for inclusion in Linux. We *have* to stop doing | this to ourselves! I expect this to be unpopular, but I've been saying lately that when new kernel APIs or syscalls or whatsoever are added to Linux, there should be sufficient docs along with the patch(es) explaining the patch and some intended uses of it, perhaps even with examples. Ingo does this sometimes. Some people don't bother to even come close. Leading by example would be a nice thing to see here. And "use the source Luke" is cool and is definitive. But it's not the only way to get things done. Well, maybe it is, but it shouldn't and needn't be. | epoll seems to be a good and desirable thing. To move forward I | believe we need to get this code reviewed, and documented. | | I can do that if you like; it will take me several weeks to get onto | it. But until that is completed I would oppose inclusion of this | code. | ------------------------------------------------------- -- ~Randy |
From: Paul L. <pl...@li...> - 2002-10-29 15:10:01
|
On Mon, 2002-10-28 at 23:28, Randy.Dunlap wrote: > I expect this to be unpopular, but I've been saying lately that > when new kernel APIs or syscalls or whatsoever are added to > Linux, there should be sufficient docs along with the patch(es) > explaining the patch and some intended uses of it, perhaps even > with examples. Ingo does this sometimes. Some people don't > bother to even come close. It would be great to see more people doing that, also releasing docs about intentions beforehand (rfc's and such) would be nice to see too. As far as example programs go, cc'ing the Linux Test Project at ltp...@li... would be a really nice thing too and make you very popular! :) Thanks, Paul Larson |
From: bert h. <ah...@ds...> - 2002-10-29 11:04:58
|
On Mon, Oct 28, 2002 at 09:09:56PM -0800, Andrew Morton wrote: > when I took a 15-minute look at this code last week I found several > bugs, some of which were grave. It's a terrible thing to say, but Are there still unresolved bugs? > epoll seems to be a good and desirable thing. To move forward I > believe we need to get this code reviewed, and documented. Davide's code explanation looks nice - do you think it sufficient? > I can do that if you like; it will take me several weeks to get onto > it. But until that is completed I would oppose inclusion of this > code. This sounds real harsh as this means that it does not, in fact, go in. I'm no guru but the code in question looks sane and reasonable. The state of the kernel right now is such that I would really advocate this going in, I'm sure we can get commitment to vet this code - which is all the easier because it is going to see more use. I'll be releasing a version of mtasker (http://ds9a.nl/mtasker) later today which uses epoll which I'm going to take into production. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO |
From: Shailabh N. <na...@wa...> - 2002-10-29 15:41:37
|
Andrew Morton wrote: > Hanna Linder wrote: > >> sys_epoll-2.5.44-last.diff > > > Folks, > > when I took a 15-minute look at this code last week I found several > bugs, some of which were grave. It's a terrible thing to say, but > a sensible person would expect that a closer inspection would turn > up more problems. > > Now, adding bugs to existing code is fine and traditional - people > find them quickly and they get fixed up. > > But for *new* code, problems will take months to discover. The only > practical way to get this code vetted for inclusion is a close review. > > And that is a sizeable task. The core implementation file is > 1,600 lines. And I wonder how many people have counted the > number of comments in there? > > Well, I'll make it easy: zero. Nil. Nada. > > (Well, OK, a copyright header, and something which got cut-n-pasted > from inode.c) > > In my wildly unconventional opinion this alone makes epoll just a hack, > of insufficient quality for inclusion in Linux. We *have* to stop doing > this to ourselves! > > > epoll seems to be a good and desirable thing. To move forward I > believe we need to get this code reviewed, and documented. > > I can do that if you like; it will take me several weeks to get onto > it. But until that is completed I would oppose inclusion of this > code. Andrew, It would be very helpful if you could point out what were the bugs you found objectionable enough to withold your approval for the patch's inclusion. It appears that the lack of comments in the code is one major concern. That alone being a reason to dismiss the sys_epoll patch seems unreasonable. Consider - there are another 3-4 months before the stable kernel will be out. In the interim, Davide with assistance from some of us IBMers can put in the desired level of comments in the code. Our committment to having a fully understood patch should be evident from the release of man pages and a detailed web page listing performance results alongwith the patch itself. - this patch is the ONLY available scalable alternative to poll() and does far better. To make an example out of this patch for not conforming to commenting standards is a little extreme. That being said, if there are bugs (small or large) that make the patch questionable, I would understand why it can't be included. But we do need to know what the bugs are. Davide had been very responsive to your last set of comments and included all of them in his patch. Please do find the time to list out atleast some of the bugs that you found. Thanks, -- Shailabh |
From: Davide L. <da...@xm...> - 2002-10-29 17:35:44
|
On Tue, 29 Oct 2002, Shailabh Nagar wrote: > Andrew, > > It would be very helpful if you could point out what were the bugs you found > objectionable enough to withold your approval for the patch's inclusion. > > It appears that the lack of comments in the code is one major concern. That alone > being a reason to dismiss the sys_epoll patch seems unreasonable. Consider > - there are another 3-4 months before the stable kernel will be out. In the > interim, Davide with assistance from some of us IBMers can put in the desired > level of comments in the code. Our committment to having a fully understood patch > should be evident from the release of man pages and a detailed web page listing > performance results alongwith the patch itself. > - this patch is the ONLY available scalable alternative to poll() and does far > better. To make an example out of this patch for not conforming to commenting > standards is a little extreme. > > That being said, if there are bugs (small or large) that make the patch > questionable, I would understand why it can't be included. But we do need to > know what the bugs are. Davide had been very responsive to your last set of > comments and included all of them in his patch. > > Please do find the time to list out atleast some of the bugs that you found. Guys, Andrew sent me suggestions about the code and I'm working with him to see what it might be improved in the current code. I think that I'll have a patch ready before the end of today ... - Davide |
From: Hanna L. <ha...@us...> - 2002-10-29 19:36:13
|
--On Tuesday, October 29, 2002 09:45:08 -0800 Davide Libenzi <da...@xm...> wrote: > > Guys, Andrew sent me suggestions about the code and I'm working with him > to see what it might be improved in the current code. I think that I'll > have a patch ready before the end of today ... > Davide, Let us know if there is anything we can help with. Hanna |
From: Davide L. <da...@xm...> - 2002-10-29 19:40:24
|
On Tue, 29 Oct 2002, Hanna Linder wrote: > --On Tuesday, October 29, 2002 09:45:08 -0800 Davide Libenzi <da...@xm...> wrote: > > > > > Guys, Andrew sent me suggestions about the code and I'm working with him > > to see what it might be improved in the current code. I think that I'll > > have a patch ready before the end of today ... > > > > Davide, > > Let us know if there is anything we can help with. Since I'm probably going to change a few things, a full performance/stability test on UP and SMP systems might help when the patch will be ready ... Thanks, Davide |
From: bert h. <ah...@ds...> - 2002-10-29 13:09:53
|
On Mon, Oct 28, 2002 at 04:57:12PM -0800, Davide Libenzi wrote: > The epoll interface has to be used with non-blocking fds. The EAGAIN > return code from read/write tells you that you can go safely to wait for > events for that fd because you making the read/write to return EAGAIN, you > consumed the whole I/O space for that fd. Consuming the whole I/O space > meant that you brought the signal to zero ( talking in ee terms ), and a > followinf 0->1 transaction will trigger the event. Where 1 means I/O space > available ... I tried to modify the mtasker webserver (http://ds9a.nl/mtasker/releases/mtasker-0.2.tar.gz) to work with epoll instead of select and, well, this is awkward. The right way to use epoll is (schematically); int clientfd=accept(); setnonblocking(clientfd); epfd=epoll_create(); epoll_ctl(epfd,EP_CTL_ADD, clientfd, POLLIN); for(;;) { if(read(clientfd)<0 && errno==EAGAIN) { epoll_wait(epfd); continue; } epoll_ctl(epfd,EP_CTL_DEL, clientfd); // remove again break; } This requires having the fd in epoll before trying to read, which means a weird interface where you have to register your interest, try to read, and unregister your interface in case it succeeded. This means two epoll syscalls per read. This is all solved if epoll_ctl() creates an edge if it finds that the poll condition is met at insert time. The way it works now is way more awkward then using regular poll(), the way it works now is very easy to do wrong because of this awkwardness. Even semi-correct which zeroes the pollstate before calling epoll is wrong: for(;;) { if(read(clientfd)<0 && errno==EAGAIN) { waitOn(clientfd); /* function which registers our interest with a central dispatcher and waits */ continue; } break; } Code like this would appear in many userspace threading abstractions, like GNU Pth or mtasker. Instead, we need: for(;;) { registerReadInterest(clientfd); if(read(clientfd)<0 && errno==EAGAIN) { waitOn(clientfd); /* function which waits for our interest be satisfied */ continue; } deleteReadInterest(clientfd); break; } If epoll_ctl make epoll_wait report an edge in case it finds that there is already data, all this is way way simpler, allowing: waitOn(clientfd); /* function which registers interest and waits for an edge to appear */ read(clientfd); Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO |
From: Davide L. <da...@xm...> - 2002-10-29 21:15:56
|
On Tue, 29 Oct 2002, bert hubert wrote: > On Mon, Oct 28, 2002 at 04:57:12PM -0800, Davide Libenzi wrote: > > > The epoll interface has to be used with non-blocking fds. The EAGAIN > > return code from read/write tells you that you can go safely to wait for > > events for that fd because you making the read/write to return EAGAIN, you > > consumed the whole I/O space for that fd. Consuming the whole I/O space > > meant that you brought the signal to zero ( talking in ee terms ), and a > > followinf 0->1 transaction will trigger the event. Where 1 means I/O space > > available ... > > I tried to modify the mtasker webserver > (http://ds9a.nl/mtasker/releases/mtasker-0.2.tar.gz) to work with epoll > instead of select and, well, this is awkward. > > The right way to use epoll is (schematically); > > int clientfd=accept(); > setnonblocking(clientfd); > > epfd=epoll_create(); > epoll_ctl(epfd,EP_CTL_ADD, clientfd, POLLIN); > > for(;;) { > if(read(clientfd)<0 && errno==EAGAIN) { > epoll_wait(epfd); > continue; > } > epoll_ctl(epfd,EP_CTL_DEL, clientfd); // remove again > break; > } > > This requires having the fd in epoll before trying to read, which means a > weird interface where you have to register your interest, try to read, and > unregister your interface in case it succeeded. > > This means two epoll syscalls per read. Bert, you don't need to do that. Like I wrote in the latest man pages, you can easily add the fd inside the interest set with POLLIN | POLLOUT when the fd born ( accept/connect ) and leave it there for its whole life. The fact that the API is edge triggered garanties you that you won't receive any events when the fd is not used. I personallt tried to measure the number of stale events and is basically ( better definitely ) uninfluent. > This is all solved if epoll_ctl() creates an edge if it finds that the poll > condition is met at insert time. > > The way it works now is way more awkward then using regular poll(), the way > it works now is very easy to do wrong because of this awkwardness. Even > semi-correct which zeroes the pollstate before calling epoll is wrong: > > for(;;) { > if(read(clientfd)<0 && errno==EAGAIN) { > waitOn(clientfd); /* function which registers our > interest with a central > dispatcher and waits */ > continue; > } > break; > } > > Code like this would appear in many userspace threading abstractions, like > GNU Pth or mtasker. Instead, we need: > > for(;;) { > registerReadInterest(clientfd); > if(read(clientfd)<0 && errno==EAGAIN) { > waitOn(clientfd); /* function which waits for our > interest be satisfied */ > continue; > } > deleteReadInterest(clientfd); > break; > } > > If epoll_ctl make epoll_wait report an edge in case it finds that there is > already data, all this is way way simpler, allowing: > > waitOn(clientfd); /* function which registers interest and waits for > an edge to appear */ > read(clientfd); You can do all this easily, expecially with API that has a core dispatch loop like GNU PTH. The example http server used to test it is an example on how to use it ( with coroutines ). Hanna, is it possible for you guys to cleanup ephttpd and make it an example program for sys_epoll ? - Davide |
From: Hanna L. <ha...@us...> - 2002-10-29 21:30:50
|
--On Tuesday, October 29, 2002 13:25:24 -0800 Davide Libenzi <da...@xm...> wrote: > Hanna, is it possible for you guys to cleanup ephttpd and make it an > example program for sys_epoll ? You mean for the man page? Sure, I will look into it. Hanna |
From: Davide L. <da...@xm...> - 2002-10-29 21:32:05
|
On Tue, 29 Oct 2002, Hanna Linder wrote: > --On Tuesday, October 29, 2002 13:25:24 -0800 Davide Libenzi <da...@xm...> wrote: > > > Hanna, is it possible for you guys to cleanup ephttpd and make it an > > example program for sys_epoll ? > > You mean for the man page? Sure, I will look into it. Not only for the man page, like a kind-of-reference possible usage ... - Davide |
From: Hanna L. <ha...@us...> - 2002-10-29 23:13:34
|
--On Tuesday, October 29, 2002 13:41:34 -0800 Davide Libenzi <da...@xm...> wrote: >> >> > Hanna, is it possible for you guys to cleanup ephttpd and make it an >> > example program for sys_epoll ? >> >> You mean for the man page? Sure, I will look into it. > > Not only for the man page, like a kind-of-reference possible usage ... Would it make sense to put sys_epoll examples in the Documentation directory? Thanks. Hanna |
From: Davide L. <da...@xm...> - 2002-10-29 23:16:14
|
On Tue, 29 Oct 2002, Hanna Linder wrote: > --On Tuesday, October 29, 2002 13:41:34 -0800 Davide Libenzi <da...@xm...> wrote: > >> > >> > Hanna, is it possible for you guys to cleanup ephttpd and make it an > >> > example program for sys_epoll ? > >> > >> You mean for the man page? Sure, I will look into it. > > > > Not only for the man page, like a kind-of-reference possible usage ... > > > Would it make sense to put sys_epoll examples in the Documentation > directory? I don't really know ... epoll does not have kernel services. IMHO this is more user space documentation. - Davide |
From: Randy.Dunlap <rdd...@os...> - 2002-10-29 23:18:40
|
On Tue, 29 Oct 2002, Hanna Linder wrote: | --On Tuesday, October 29, 2002 13:41:34 -0800 Davide Libenzi <da...@xm...> wrote: | >> | >> > Hanna, is it possible for you guys to cleanup ephttpd and make it an | >> > example program for sys_epoll ? | >> | >> You mean for the man page? Sure, I will look into it. | > | > Not only for the man page, like a kind-of-reference possible usage ... | | | Would it make sense to put sys_epoll examples in the Documentation | directory? You mean in the linux/Documentation/ directory? No, please don't litter it up like that. -- ~Randy |
From: John G. M. <jg...@ne...> - 2002-10-29 21:49:44
|
bert hubert wrote: >That is a semantics change and not an API/ABI change. > An API/ABI encompasses the semantics of the calls. A change to the semantics is a change to the API/ABI. >I bet Davide knows best. > Nope, he doesn't. >An easy solution is to have sys_epoll_ctl check if there is there is data >ready and make sure there is an edge to report in that case to the next call >of sys_epoll_ctl(). > > This is the very solution I am proposing. |