Asynchronicity in D

Max Klyga max.klyga at gmail.com
Thu Mar 31 16:30:27 PDT 2011


On 2011-04-01 01:45:54 +0300, Jonas Drewsen said:

> On 31/03/11 23.20, Max Klyga wrote:
>> On 2011-03-31 22:35:43 +0300, Jonas Drewsen said:
>> 
>>> On 31/03/11 18.26, Andrei Alexandrescu wrote:
>>>> snip
>>> 
>>> I believe that we would need both the threaded async IO that you
>>> describe but also a select based one. The thread based is important
>>> e.g. in order to keep buffering incoming data while processing
>>> elements in the range (the OS will only buffer the number of bytes
>>> allowed by sysadmin). The select based is important in order to handle
>>> _many_ connections at the same time (think D as the killer app for
>>> websockets). As Robert mentions fibers would be nice to take into
>>> consideration as well.
>>> 
>>> What I also see as an unresolved issue is non-blocking handling in
>>> http://erdani.com/d/phobos/std_stream2.html which fits in naturally
>>> with this topic I think.
>>> 
>>> I may very well agree mentoring if we get a solid proposal out of this.
>> 
>> I'm very glad to hear this. Now my motivation doubled!
>>> 
>>> /Jonas
>> 
>> Any comments, if this proposal be more focused on asyncronous networking
>> or should it address asyncronisity in Phobos in general?
>> 
>> I researched a little about libev and libevent. Both seem to have some
>> limitations on Windows platform.
>> 
>> libev can only be used to deal with sockets on Windows and uses select,
>> which limits libev to 64 file handles per thread.
> 
> Actually it seems the limit is OS version dependent and for NT it is 
> 32767 per process: http://support.microsoft.com/kb/111855

That page also mentions that actual limit is 64 by default and is 
adjustable, but requires recompilation, because it is defined in a 
macro (FD_SETSIZE).
> 
>> libevent uses Windows overlaping I/O, but this thread[1] shows that
>> current implementation has perfomance limitations.
>> So one option may be to use either libev or libevent, and implement
>> things on top of them.
>> Another is to make a new implementation (from scratch, or reuse some
>> code from Boost.ASIO[2]) using threads or fibers, or maybe both.
>> 
>> 1. http://www.mail-archive.com/libevent-users@monkey.org/msg01730.html
>> 2. http://www.boost.org/doc/libs/1_46_1/doc/html/boost_asio.html




More information about the Digitalmars-d mailing list