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.
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
