std.asio?

[Robert]

On Mon, 2013-03-11 at 17:06 +0100, Martin Drasar wrote:
> Hi,
> 
> I started to work on a networking heavy project and I found out that
> there is nothing like boost.asio in D's standard library. So I looked
> around and discovered that vibe.d has nice fiber-based asynchronous
> library, but sadly it does not play along well with threads. Then I
> looked some more and found nothing else... (this can of course mean that
> I can't search)
> 
> I have hacked a solution that implements more or less what I need, but
> it got me thinking that such thing would be very useful in standard
> library. So I have some questions (in descending order of importance):
> 
> - Is there some asynchronous networking library for D out there?
> - Is somebody working on such library?
> - Is there a plan to work on such library that may be held back by
> insufficient manpower or by yet-to-be-added libraries like the new I/O?
> - If there is nothing and nobody is working on it, what would be the
> best course of action if I wanted to do it?
> DIP -> implementation -> experimetnal -> std?
> list discussion -> implementation -> experimental -> std?
> implementation <-> discussion -> experimental -> std?
> some other permutation?
> 
> Any other thoughts?
> 
> Cheers,
> Martin

I had plans to implement something like this, but at the moment I am
stuck with other important things. I absolutely agree that something
like boost::asio::io_service should be part of the standard library, so
the situation we have in C++ where every library implements its own
event queue could be avoided. (E.g. the only really working way to use
Qt and boost::asio together is by using multiple threads) I would love
to avoid this in D. 

Ideally we would have asynchronous primitives and a synchronous
interface compatible to regular streams like the upcoming std.stream
based on fibers and an event queue. This way also higher level libraries
building on std.stream like a db abstraction library would automatically
offer asynchronous operation by simply replacing the used stream with an
asynchronous fiber based one.

Just in a nutshell what I would try to implement, the moment I get to
this item on my todo list. Although I would contact Soenke first, as he
already has a lot of experience with fiber based IO.

Regarding your problems with vibe, what is your particular problem with
threads? Have you asked about your problems on
http://news.rejectedsoftware.com/groups/rejectedsoftware.vibed/ ?

Maybe they are easily solved? I don't use vibe multi-threaded currently,
but if it does not work now, it seems that it is worked on. Also Soenke
is usually glad about pull requests ;-)

Best regards,

Robert