Remember that Go vs D MQTT thing and how we wondered about dmd vs gdc?

[Sönke Ludwig]

Am 07.03.2014 22:11, schrieb Bienlein:
>> One question - doesn't Vibe.d already use green threads?
>
> What they are saying on their web site is that they are using fibers and
> at the same time they say they are using libevent. That is confusing for
> me. On http://vibed.org/features they write: "Instead of using classic
> blocking I/O together with multi-threading for doing parallel network
> and file operations, all operations are using asynchronous operating
> system APIs. By default, >>libevent<< is used to access these APIs
> operating system independently."
>
> Further up on the same page they write: "The approach of vibe.d is to
> use asynchronous I/O under the hood, but at the same time make it seem
> as if all operations were synchronous and blocking, just like ordinary
> I/O. What makes this possible is D's support for so called >>fibers<<".
>
>> It does. Bienlein has a very vague knowledge of topics he
>> comments about.
>
> I thought the vibe.d guys would shed some light at this at the occasion,
> but no luck. What I don't understand is how fibers can listen to input
> that comes in through connections they hold on to. AFAIKS, a fiber only
> becomes active when it's call method is called. So who calls the call
> method in case a connection becomes active? That is then again a kernel
> thread? How does the kernel thread know something arrived through a
> connection? It can't do a blocking wait as the system would run out of
> kernel threads very quickly.

Sorry, I've been busy with some non-programming business over the past 
days and didn't have a chance to reply. Making a small article about the 
internal workings of the task/fiber system is planned for a long time 
now, but there are so many items with higher priority that it 
unfortunately hasn't happened so far. See my reply [1] in the other 
thread for a rough outline.

>> I think what Go and Erlang do is to use green threads (or equivalent,
>> goroutines in Go) for the applications side and a kernel thread pool
>> within the runtime doing "work stealing" on the green threads. This is
>> more or less (ish) what the Java Fork/Join framework of Doug Lea does as
>> well.
>
> When in Go a channel runs empty the scheduler detaches the thread that
> served it and attaches it to a non-empty channel. In Go all this is in
> the language and the runtime where it can be done more efficiently than
> in a library. AFAIU, this is a main selling point in Go.

I actually don't see a reason why it can't be just as efficient when 
done as a library. Taking the example of vibe.d, fibers are currently 
never moved between threads (although technically, they could), but they 
are still stored in a free list and reused for later tasks. There is not 
much more overhead than a few variable assignments and the fiber context 
switches.

>
>> Vert.x is caliming to be able to handle millions of active connections.
>
> All right, as you can't have millions of threads on the JVM they must do
> that through some asynchronous approach (I guess Java NewIO). I read
> that an asynchronous solution is not as fast as one with many blocking
> threads as in Go or Erlang. I don't understand why. It was just claimed
> that this were the case.

AFAIK they use a combination of callback based asynchronous I/O (mostly 
for server applications) combined with a thread pool for parallelizing 
synchronous I/O (mostly for client type applications/tasks). So it's 
basically a hybrid system that still makes a lot of trade-offs between 
performance and comfort. Disclaimer: this statement is based only on 
looking at a few examples and maybe a bog post, I don't have any first 
hand experience with vert.x.