www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - InSocket: Use epoll instead of select

reply chmike <christophe_no_spam meessen.net> writes:
Hello,

I am considering using D for an ORB like application and I am confused about
Socket class providing select. select is known for years to be inefficient.
Various solutions have been proposed to solve this and the later one (epoll)
is the most efficient one.

D should really consider moving to epoll API. I am using epoll for my server
applications.  To keep my code portable on windows I wrote the three epoll API
calls wrapping use of select inside.

select requires to poll sockets for event, where epoll returns a list of
socket that had an event. The effort with select is proportional to the number
of sockets regardless of their activity. With epoll it is proportional to the
effective activity. idle connections don't waste CPU. epoll scales very well.
Jan 11 2007
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
chmike wrote:


 Hello,
 
 I am considering using D for an ORB like application and I am confused
 about Socket class providing select. select is known for years to be
 inefficient. Various solutions have been proposed to solve this and the
 later one (epoll) is the most efficient one.
 
 D should really consider moving to epoll API. I am using epoll for my
 server
 applications.  To keep my code portable on windows I wrote the three epoll
 API calls wrapping use of select inside.
 
 select requires to poll sockets for event, where epoll returns a list of
 socket that had an event. The effort with select is proportional to the
 number of sockets regardless of their activity. With epoll it is
 proportional to the effective activity. idle connections don't waste CPU.
 epoll scales very well.


Tango will when released, provide a Selector interface that provide the most
efficient ways to do non-blocking IO on the different platforms, including
epoll where available.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Dancing the Tango
Jan 11 2007
parent reply chmike <christopheXXX meessen.net> writes:
I'm new to D and find the language specifications very attractive.
It is a very good news that the language specification v1 have been frozen. I
hope
that libraries in project reach this stage soon.

What is the status of Tango ?
Where are the specification/documentation ?
Jan 11 2007
parent Sean Kelly <sean f4.ca> writes:
chmike wrote:

 I'm new to D and find the language specifications very attractive.
 It is a very good news that the language specification v1 have been frozen. I
hope
 that libraries in project reach this stage soon.
 
 What is the status of Tango ?


The code overall is in good shape.  A few packages are still a little 
rough around the edges, but they are for higher-level features (like 
FTP) and are being worked on as we speak.


 Where are the specification/documentation ?


Access to the website is currently restricted as we get the 
documentation finished.


Sean
Jan 11 2007
prev sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Thu, 11 Jan 2007 08:07:01 -0500, chmike  
<christophe_no_spam meessen.net> wrote:


 Hello,

 I am considering using D for an ORB like application and I am confused  
 about
 Socket class providing select. select is known for years to be  
 inefficient.
 Various solutions have been proposed to solve this and the later one  
 (epoll)
 is the most efficient one.

 D should really consider moving to epoll API. I am using epoll for my  
 server
 applications.  To keep my code portable on windows I wrote the three  
 epoll API
 calls wrapping use of select inside.

 select requires to poll sockets for event, where epoll returns a list of
 socket that had an event. The effort with select is proportional to the  
 number
 of sockets regardless of their activity. With epoll it is proportional  
 to the
 effective activity. idle connections don't waste CPU. epoll scales very  
 well.


It was known that select() is pretty inefficient, but was provided because  
it's most portable and something to get your project going. Alternatives  
were considered but not yet pursued.
Jan 11 2007
parent Dejan Lekic <dejan.lekic gmail.com> writes:
As previously stated select() is the most portable way. If you look for the
most efficient, than Real-time Signals are probably the best.

libevent project have support for all of them.
http://monkey.org/~provos/libevent/

Kind regards

Dejan


 It was known that select() is pretty inefficient, but was provided because  
 it's most portable and something to get your project going. Alternatives  
 were considered but not yet pursued.
Jan 11 2007