API compatible to poll() and epoll() of Linux

  • Thread starter Thread starter Rajat
  • Start date Start date
R

Rajat

Hi All,

I am looking for some APIs in window that have the smilar
functionalities provided by poll() or epoll() in Linux, for socket
programming.

Anyone have any idea??

Rajat.
 
Rajat said:
Hi All,

I am looking for some APIs in window that have the smilar
functionalities provided by poll() or epoll() in Linux, for socket
programming.

Anyone have any idea??
Click to expand...

On Windows you need to use 'overlapped I/O' or 'I/O completion ports' to get the
same scalability.
 
Don't poll and select do essentialy the same thing? Maybe I didn't
quite understand your question...

--K-sPecial
 
:Don't poll and select do essentialy the same thing?

poll() can be used to get finer-grained information about the state
of a particular file descriptor; select() can be used to get cruder
information about a set of file descriptors.
Click to expand...

Poll() is also more efficient if there are lots of descriptors involved.
When select() returns, you have to search through all the descriptors
looking for the ones that became readable/writable, while poll() simply
returns the list of readable/writable descriptors.
 
poll() can be used to get finer-grained information about the state
of a particular file descriptor; select() can be used to get cruder
information about a set of file descriptors.
Click to expand...

Poll() is also more efficient if there are lots of descriptors involved.
When select() returns, you have to search through all the descriptors
looking for the ones that became readable/writable, while poll() simply
returns the list of readable/writable descriptors.[/QUOTE]

More than that, a classic BSD kernel implementation of select() involved
sowakeup() to awakening all processes in the system stuck select() so
that each process can search its bit masks for a descriptor that
justifies returning to user mode. That works ok on a tiny system like
a VAX 780, but it's kind of slow on systems with lots of network jobs.
It's really painful on multi-processors with more than a trivial number
of CPUs because of the inter-CPU chatter required for locking file
descriptors and so forth.


Vernon Schryver (e-mail address removed)
 
[comp.os.ms-windows.networking.* removed from followup list, since this
is now about POSIX and Unix APIs.]

Poll() is also more efficient if there are lots of descriptors involved.
When select() returns, you have to search through all the descriptors
looking for the ones that became readable/writable, while poll() simply
returns the list of readable/writable descriptors.
Click to expand...

More than that, a classic BSD kernel implementation of select() involved
sowakeup() to awakening all processes in the system stuck select() so
that each process can search its bit masks for a descriptor that
justifies returning to user mode.[/QUOTE]

Agreed. poll also doesn't suffer from select's FD_SETSIZE limit.
FD_SETSIZE can be changed at compile time, but that's inflexible and
wastes space if the app frequently only has a few descriptors in the
set. Or an app can maintain its own dynamically-sized FD_SETs, but
then the FD_* macros won't work. And overflowing FD_SETs was
recently documented as a security hole in a number of applications.
 
Back
Top