On 2014-03-07 21:11:12 +0000, Bienlein said:
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<<".
That is all correct. Libevent supplies the polling an async io. D
provides the ability to do fibers. Mixed together you get a very
probust, easy to program, scalable, web platform. See below.
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.
Fibers are cooperatively multitasked routines. Whenever vibe-d uses a
libevent IO function, it yields it's current operation back to the
event loop. When a libevent poll indicates there is data waiting, it
resumes that fiber where it was left off. The vibe-d event loop is
essentially the scheduler for the fibers.
