http://groups.google.com/groups?hl=en&lr=&safe=off&ic=1&th=92342b6dca5ab8cf,7&seekm=37580D22.1D6D693%40yahoo.com#p Advanced Groups Search Groups Help Search all groups Search the Web Messages from the thread "select() vs. poll()" Messages 1 - 7 of 7. Message 1 in thread From: chakie@infa.abo.fi (chakie@infa.abo.fi) Subject: select() vs. poll() Newsgroups: comp.os.linux.development.system Date: 1999/06/04 Hi there, I was wondering what is the practical difference between the functions 'select()' and 'poll()'? I've used the former quite a lot, but stumbled over the latter today. poll() seems to have entered Linux quite recently, and I think the interface it provides is nicer then select(). Is there something I should be aware of if I intend to use poll() instead of select()? Performance? Thread-safety (I use threads)? Stability? I'd appreciate in opinions/warnings/suggestions about this issue. Have you used poll() without problems? Regards, Jan Ekholm -- ---------------------+------------------------------------------------------ Jan 'Chakie' Ekholm | CS at Abo Akademi University, Turku, Finland Linux Inside | I'm the blue screen of death, no-one hears you scream Message 2 in thread From: G. Sumner Hayes (sjhalpar@yahoo.com) Subject: Re: select() vs. poll() Newsgroups: comp.os.linux.development.system Date: 1999/06/04 chakie@infa.abo.fi wrote: > I was wondering what is the practical difference between the functions > 'select()' and 'poll()'? I've used the former quite a lot, but stumbled > over the latter today. poll() seems to have entered Linux quite > recently, and I think the interface it provides is nicer then select(). poll() has been around at least since 1.3.x kernels, so for a few years anyway. > Is there something I should be aware of if I intend to use poll() > instead of select()? Performance? poll() is moderately more efficient than select() on Linux. > Thread-safety (I use threads)? Stability? Both are thread safe and stable. select() is somewhat more portable. If performance with large numbers of fds is important then you probably want to use autoconf to check for poll() and use it if possible; otherwise go with select(). Neither is highly scalable, so schemes that fork multiple process and divide up fds between them are used in large servers. The real-time queued I/O completion signals available in Linux 2.2 with glibc 2.1 are an effort to improve matters. Richard Gooch has some patches to old kernels that can increase poll/select performance by a factor of 3 or more in case you can't change to use the signals -- I believe they're planned for inclusion in the 2.3.x development series of kernels. Thread safety is there, but efficiency in SMP setups is not. All processes that are polling (or selecting) on an fd are woken when it's available -- that can lead to a thundering herds problem if you have a ton of processes polling on one fd (common in some thread models). The wake-one accept() in the early 2.3.x kernels is there to help deal with this, and further wake-one semantics are planned for other interfaces in the 2.3.x kernels. select() on linux (since 2.0.x) is implemented as a wrapper around poll(). So if poll is broken then select is broken, but the converse is not necessarily true. And select obviously can't be more efficient than poll. In older (some 1.3.x, possibly 1.2.x and earlier) Linux kernels, poll() was a wrapper around select(). This was inefficient and I'm not sure it was possible to get the semantics right. --Sumner Message 3 in thread From: chakie@infa.abo.fi (chakie@infa.abo.fi) Subject: Re: select() vs. poll() Newsgroups: comp.os.linux.development.system Date: 1999/06/07 G. Sumner Hayes wrote: : chakie@infa.abo.fi wrote: :> I was wondering what is the practical difference between the functions :> 'select()' and 'poll()'? I've used the former quite a lot, but stumbled :> over the latter today. poll() seems to have entered Linux quite :> recently, and I think the interface it provides is nicer then select(). : poll() has been around at least since 1.3.x kernels, so for a few : years anyway. Ok, the man-page says that the 'systemcall' poll() was introduced in 2.1.23, but the wrapper around select() is probably much older. :> Thread-safety (I use threads)? Stability? : Both are thread safe and stable. select() is somewhat more portable. : If performance with large numbers of fds is important then you : probably want to use autoconf to check for poll() and use it if : possible; otherwise go with select(). Yep, but it can be quite hard to do in practically, as the syntax of the calls are very different. My code is basically Linux-specific (IMHO it's quite hard to get apps using a lot of net-code to compile nicely on multiple platforms), so I'll switch to poll(). The syntax is cleaner and seems less 'hackish' to me. : Neither is highly scalable, : so schemes that fork multiple process and divide up fds between them : are used in large servers. Hmm, I've been thinking about that. My app can have a maximum of 250 clients (should never happen though) and that traversing (worst case) all them can take some time. : Thread safety is there, but efficiency in SMP setups is not. All : processes that are polling (or selecting) on an fd are woken when : it's available -- that can lead to a thundering herds problem if : you have a ton of processes polling on one fd (common in some thread : models). The wake-one accept() in the early 2.3.x kernels is there : to help deal with this, and further wake-one semantics are planned : for other interfaces in the 2.3.x kernels. I don't have multiple threads using the same fd, so this shouldn't be a problem. Thanks for the comments and help, they convinced me that it will be worth to convert to poll() in my app! Regards, Chakie -- ---------------------+------------------------------------------------------ Jan 'Chakie' Ekholm | CS at Abo Akademi University, Turku, Finland Linux Inside | I'm the blue screen of death, no-one hears you scream Message 4 in thread From: Bj©ªrn Reese (breese@mail1.stofanet.dk) Subject: Re: select() vs. poll() Newsgroups: comp.os.linux.development.system Date: 1999/06/07 chakie@infa.abo.fi wrote: > calls are very different. My code is basically Linux-specific (IMHO it's > quite hard to get apps using a lot of net-code to compile nicely on > multiple platforms), so I'll switch to poll(). The syntax is cleaner and poll() is not Linux-specific. It is part of the UNIX98 standard (the successor of POSIX) and supported by most recent Unices. For example, on Solaris select() is a wrapper for poll(). However, select() is still more portable as it is supported on most older Unices and several non-Unix platforms, such as OS/2 and Win32. You can find the UNIX98 standard at http://www.opengroup.org/onlinepubs/7908799/toc.htm Message 5 in thread From: G. Sumner Hayes (sjhalpar@yahoo.com) Subject: Re: select() vs. poll() Newsgroups: comp.os.linux.development.system Date: 1999/06/07 Bj©ªrn Reese wrote: > However, select() is still more portable as it is > supported on most older Unices and severe different. select()ing on things other than network sockets doesn't work, in general. WaitForMultipleObjects* and WSAAsyncSelect are preferred. If you're just working with sockets, select() out to work (though a socket fd isn't a small positive integer and other stuff is screwy). --Sumner Message 6 in thread From: Bj©ªrn Reese (breese@mail1.stofanet.dk) Subject: Re: select() vs. poll() Newsgroups: comp.os.linux.development.system Date: 1999/06/08 "G. Sumner Hayes" wrote: > Caveat: On Win32 the semantics are different. select()ing on > things other than network sockets doesn't work, in general. > WaitForMultipleObjects* and WSAAsyncSelect are preferred. Yes, along with the other Win32 related problems, such as select() only being able to handle 64 sockets, and the synchronization bug which has to be worked around with a Sleep(). Message 7 in thread From: Bill Zimmerly (billz@inlink.com) Subject: Re: select() vs. poll() Newsgroups: comp.os.linux.development.system Date: 1999/06/09 Bjorn, Do you mind elaborating a bit on the "synchronization bug" that you wrote about here? Is there a website that you can direct me to that covers this? I'm asking this because I am seeing what appears to be a socket problem in Win32, but am not sure that it's the same thing as the bug you wrote about. Many thanks for pointing this out! - Bill Bj©ªrn Reese wrote in message news:375D4D89.BFA81F53@mail1.stofanet.dk... > "G. Sumner Hayes" wrote: > > > Caveat: On Win32 the semantics are different. select()ing on > > things other than network sockets doesn't work, in general. > > WaitForMultipleObjects* and WSAAsyncSelect are preferred. > > Yes, along with the other Win32 related problems, such as select() > only being able to handle 64 sockets, and the synchronization bug > which has to be worked around with a Sleep(). Google Web Directory - Cool Jobs - Advertise with Us - Add Google to Your Site - Google in Your Language - All About Google ¨Ï2001 Google http://groups.google.com/groups?hl=en&lr=&safe=off&ic=1&th=74e59a41fe0a7528,14&seekm=Pine.A41.3.96.990716151622.161148A-100000%40vcmr-19.rcs.rpi.edu#p Advanced Groups Search Groups Help Search all groups Search the Web Messages from the thread "IO Completion Ports" Messages 1 - 10 of 14. Jump to [ End of thread (newest) ] Message 1 in thread From: Matthew Carl Schumaker (schumm@rpi.edu) Subject: IO Completion Ports Newsgroups: comp.os.linux.development.apps, comp.os.linux.development.system Date: 1999/07/16 I've been trying to find info about IO completion ports under linux but the only info I have dates back to May of 1998 Anybody know if there has been any progress on that front? Pointers to Info? thanks in advance matt Matthew Carl Schumaker UPAC Lights Administrative Chairperson schumm@rpi.edu veni, vedi, velcro I came, I saw, I stuck around Message 2 in thread From: Kaz Kylheku (kaz@ashi.FootPrints.net) Subject: Re: IO Completion Ports Newsgroups: comp.os.linux.development.apps, comp.os.linux.development.system Date: 1999/07/16 On Fri, 16 Jul 1999 14:49:56 -0400, Matthew Carl Schumaker wrote: >I've been trying to find info about IO completion ports under linux >but the only info I have dates back to May of 1998 Linux doesn't have IO completion ports. This is a Windows NT (and possibly VAX?) concept. >Anybody know if there has been any progress on that front? In the POSIX world, the rough equivalent is asynchronous I/O, so the question would be what the status of *that* is. Message 3 in thread From: Matthew Carl Schumaker (schumm@rpi.edu) Subject: Re: IO Completion Ports Newsgroups: comp.os.linux.development.apps, comp.os.linux.development.system Date: 1999/07/16 Matthew Carl Schumaker UPAC Lights Administrative Chairperson schumm@rpi.edu veni, vedi, velcro I came, I saw, I stuck around On Fri, 16 Jul 1999, Kaz Kylheku wrote: > On Fri, 16 Jul 1999 14:49:56 -0400, Matthew Carl Schumaker > wrote: > >I've been trying to find info about IO completion ports under linux > >but the only info I have dates back to May of 1998 > > Linux doesn't have IO completion ports. This is a Windows NT (and possibly > VAX?) concept. > I found some messages in the kernel mailing list about a patch that implemented IO completion Ports that was the reason why I asked > >Anybody know if there has been any progress on that front? > > In the POSIX world, the rough equivalent is asynchronous I/O, so the > question > would be what the status of *that* is. > > I would prefer not to use the Linux POSIX AIO implementation because (I've heard/read, I haven't actually looked at the source yet) it does it in Userspace and spawns multiple threads to do it. Again I'm not sure about the above Message 4 in thread From: Holy Cow (hcow@cowspam.org) Subject: Re: IO Completion Ports Newsgroups: comp.os.linux.development.apps, comp.os.linux.development.system Date: 1999/07/16 Matthew Carl Schumaker wrote: > > I've been trying to find info about IO completion ports under linux I never heard of this under linux--it's an NT thing. Doesn't 'select' do kind of similar something? -- len if you must email, reply to: len bel at world net dot att dot net (no spaces, ats2@, dots2.) Message 5 in thread From: Arun Sharma (adsharma@home.com.nospam) Subject: Re: IO Completion Ports Newsgroups: comp.os.linux.development.apps, comp.os.linux.development.system Date: 1999/07/16 On Fri, 16 Jul 1999 15:24:39 -0400, Matthew Carl Schumaker wrote: > I would prefer not to use the Linux POSIX AIO implementation because (I've > heard/read, I haven't actually looked at the source yet) it does > it in Userspace and spawns multiple threads to do it. > Again I'm not sure about the above If you look into glibc, that's how it's done. For each async I/O requests are queued and if necessary threads are created, which do I/O synchronously and on completion, notify the caller using a signal. Again, the argument is that thread creation overhead in Linux is low enough to allow it. -Arun Message 6 in thread From: Miquel van Smoorenburg (miquels@cistron.nl) Subject: Re: IO Completion Ports Newsgroups: comp.os.linux.development.apps, comp.os.linux.development.system Date: 1999/07/17 In article , Kaz Kylheku wrote: >On Fri, 16 Jul 1999 14:49:56 -0400, Matthew Carl Schumaker >wrote: >>I've been trying to find info about IO completion ports under linux >>but the only info I have dates back to May of 1998 > >Linux doesn't have IO completion ports. This is a Windows NT (and possibly >VAX?) concept. Linux does have it now, in 2.2. You can have posix queued signals delivered when something happens on a file descriptor. I don't know the details- you'll have to search the kernel mailing list for posts of Stephen Tweedie on the subject. Mike. -- Beware of Programmers who carry screwdrivers. Message 7 in thread From: David Schwartz (davids@webmaster.com) Subject: Re: IO Completion Ports Newsgroups: comp.os.linux.development.apps, comp.os.linux.development.system Date: 1999/07/26 I don't think you would want this, in general. The reason people use I/O Completion ports on NT is because it is the fastest way to do network I/O. If a Linux implementation wasn't the fastest way to do network I/O, it wouldn't be particularly interesting. Under current Linux implementations, poll is the fastest way to do network I/O, so you should use it. DS Matthew Carl Schumaker wrote: > > I've been trying to find info about IO completion ports under linux > but the only info I have dates back to May of 1998 > > Anybody know if there has been any progress on that front? > Pointers to Info? > > thanks in advance > matt > > Matthew Carl Schumaker > UPAC Lights Administrative Chairperson > schumm@rpi.edu > veni, vedi, velcro > I came, I saw, I stuck around Message 8 in thread From: Mr Williams (hwilliams@dont_send.org) Subject: Re: IO Completion Ports Newsgroups: comp.os.linux.development.apps, comp.os.linux.development.system Date: 1999/07/26 David Schwartz wrote: > I don't think you would want this, in general. The reason people use > I/O Completion ports on NT is because it is the fastest way to do > network I/O. David, this is a piece of bunk. I/O completion ports are used to keep the expense of thread creation and the number of threads down--on one hand, and to avoid unnecessary context switching, on the other. It's got very little to do with network I/O per se, and can be used for anything else. Functionally, there's nothing about linux that makes completion ports unnecessary, it would in fact be good to have such a mechanism available. But, they're simply not available there, that's all (well, 'select' kind of does a similar thing.) > If a Linux implementation wasn't the fastest way to do > network I/O, it wouldn't be particularly interesting. Under current > Linux implementations, poll is the fastest way to do network I/O, so you > should use it. Hopefully the guy knows better than to take this thing at its face value. -- len if you must email, reply to: len bel at world net dot att dot net (no spaces, ats2@, dots2.) Message 9 in thread From: Andi Kleen (ak-uu@muc.de) Subject: Re: IO Completion Ports Newsgroups: comp.os.linux.development.apps, comp.os.linux.development.system Date: 1999/07/26 David Schwartz writes: I don't think you would want this, in general. The reason people use > I/O Completion ports on NT is because it is the fastest way to do > network I/O. If a Linux implementation wasn't the fastest way to do > network I/O, it wouldn't be particularly interesting. Under current > Linux implementations, poll is the fastest way to do network I/O, so you > should use it. Actually queued SIGIO is faster in 2.2 (at least when a huge number of fds is involved) -Andi -- This is like TV. I don't like TV. Message 10 in thread From: nbecker@fred.net (nbecker@fred.net) Subject: Re: IO Completion Ports Newsgroups: comp.os.linux.development.apps, comp.os.linux.development.system Date: 1999/07/27 >>>>> "Williams" == Williams writes: Wd in fact be good to have such a mechanism Williams> available. But, they're simply not available there, that's all (well, Williams> 'select' kind of does a similar thing.) But posix aysnc io IS there. You need glibc-2.1. Isn't that what you want? Next 4 messages in thread Displaying messages 1 - 10 of 14. Jump to [ End of thread (newest) ] Google Web Directory - Cool Jobs - Advertise with Us - Add Google to Your Site - Google in Your Language - All About Google ¨Ï2001 Google Advanced Groups Search Groups Help Search all groups Search the Web Messages from the thread "IO Completion Ports" Messages 11 - 14 of 14. Previous 10 Jump to [ Start of thread (oldest) ] Message 11 in thread From: David Schwartz (davids@webmaster.com) Subject: Re: IO Completion Ports Newsgroups: comp.os.linux.development.apps, comp.os.linux.development.system Date: 1999/09/30 Andi Kleen wrote: > > David Schwartz writes: > > I don't think you would want this, in general. The reason people use > > I/O Completion ports on NT is because it is the fastest way to do > > network I/O. If a Linux implementation wasn't the fastest way to do > > network I/O, it wouldn't be particularly interesting. Under current > > Linux implementations, poll is the fastest way to do network I/O, so you > > should use it. > > Actually queued SIGIO is faster in 2.2 (at least when a huge number of > fds is involved) > > -Andi Is this really true? I've got to think that it's faster for me to do one poll call and find out that 5,000 file descriptors are ready for I/O than for me to receive 5,000 queued signals. DS Message 12 in thread From: Andi Kleen (ak-uu@muc.de) Subject: Re: IO Completion Ports Newsgroups: comp.os.linux.development.apps, comp.os.linux.development.system Date: 1999/10/02 David Schwartz writes: > Andi Kleen wrote: > > > > David Schwartz writes: > > > > I don't think you would want this, in general. The reason people > > use > > > I/O Completion ports on NT is because it is the fastest way to do > > > network I/O. If a Linux implementation wasn't the fastest way to do > > > network I/O, it wouldn't be particularly interesting. Under current > > > Linux implementations, poll is the fastest way to do network I/O, so you > > > should use it. > > > > Actually queued SIGIO is faster in 2.2 (at least when a huge number of > > fds is involved) > > > > -Andi > > Is this really true? I've got to think that it's faster for me to do > one poll call and find out that 5,000 file descriptors are ready for I/O > than for me to receive 5,000 queued signals. The kernel internally does lots of table walks for poll/select. Just queueing an event is a lot faster and scales much better. Of course the Linux kernel could be fixed to cache the poll table and use such a event system internally (like Solaris does), but so far it doesn't. Just handing the events over to user space is easier too. -Andi -- This is like TV. I don't like TV. Message 13 in thread From: David Schwartz (davids@webmaster.com) Subject: Re: IO Completion Ports Newsgroups: comp.os.linux.development.apps, comp.os.linux.development.system Date: 1999/11/04 Andi Kleen wrote: > The kernel internally does lots of table walks for poll/select. Just > queueing an event is a lot faster and scales much better. > > Of course the Linux kernel could be fixed to cache the poll table and use > such a event system internally (like Solaris does), but so far it doesn't. > > Just handing the events over to user space is easier too. > > -Andi > -- > This is like TV. I don't like TV. On a related note, is there any version of Linux that can successfully poll on more than 16,384 fds? I keep getting: kmalloc: Size (160000) too large kmalloc: Size (160000) too large kmalloc: Size (160000) too large kmalloc: Size (160000) too large kmalloc: Size (160000) too large DS Message 14 in thread From: M. David Allen (x@localhost.localdomain) Subject: Re: IO Completion Ports Newsgroups: comp.os.linux.development.apps, comp.os.linux.development.system Date: 1999/11/05 In article <3821434C.F5EFF353@webmaster.com>, David Schwartz writes: > Andi Kleen wrote: > >> The kernel internally does lots of table walks for poll/select. Just >> queueing an event is a lot faster and scales much better. >> >> Of course the Linux kernel could be fixed to cache the poll table and use >> such a event system internally (like Solaris does), but so far it doesn't. >> >> Just handing the events over to user space is easier too. >> >> -Andi >> -- >> This is like TV. I don't like TV. > > On a related note, is there any version of Linux that can successfully > poll on more than 16,384 fds? I keep getting: > > kmalloc: Size (160000) too large > kmalloc: Size (160000) too large > kmalloc: Size (160000) too large > kmalloc: Size (160000) too large > kmalloc: Size (160000) too large > DS Uh, I don't know if that was a tyop or not, but kmalloc is telling you that 160,000 is too large, not 16,000. -- David Allen http://opop.nols.com/ ---------------------------------------- Israeli girls arent nearly as promiscuous as american girls American girls arn't nearly as promiscuous as they should be. Displaying messages 11 - 14 of 14. Jump to [ Start of thread (oldest) ] Google Web Directory - Cool Jobs - Advertise with Us - Add Google to Your Site - Google in Your Language - All About Google ¨Ï2001 Google