Am 16.04.2014 16:43, schrieb Bienlein:
On Wednesday, 16 April 2014 at 14:21:03 UTC, Sönke Ludwig wrote:I still don't understand what you mean by "distributed". Spawning 50.000 tasks: import vibe.core.core; import std.stdio; void main() { foreach (i; 0 .. 50_000) runTask({ writefln("Hello, World!"); }); } Alternatively, runWorkerTask will also distribute the tasks among a set of worker threads, which would be more in line with Go AFAIK.All right, I see. I spent some time looking at the vibe.d homepage and I never saw any other code than something like this: shared static this() { auto settings = new HTTPServerSettings; settings.port = 8080; listenHTTP(settings, &handleRequest); } void handleRequest(HTTPServerRequest req, HTTPServerResponse res) { res.writeBody("Hello, World!", "text/plain"); } Not wanting just to be right, but things like that should still be in some base library of the language and not in some 3rd party library. The vibe.d homepage says "As soon as a running fiber calls a special yield() function, it returns control to the function that started the fiber.". Yielding in the FiberScheduler by Sean Kelly is transparent. That's an important point to be easy to use, I think. Also the use of libevent is mentioned. I don't understand what the implications of that exactly is.
It *is* transparent. Once a blocking operation, such as I/O or waiting for a message, is triggered, it will implicitly yield. But the text indeed doesn't make it very clear. The explicit yield() function is meant for (rare) cases where more control is needed, for example during lengthy computations.
Libevent is just an abstraction layer above the various asynchronous I/O APIs. It provides a platform independent way to get notified about finished operations. There is also a native WinAPI based implementation that enables integration with GUI applications.
What I mean is that some nice transparent solution in a base library for the "some ten thousand threads thing" would be nice.
That would indeed be nice to have in the standard library, but it also needs to be carefully planned out, as it has a lot of implications on the existing code, such as making all blocking functions compatible with the fiber based model. Without a full work over it will most likely do more harm than good. And having it in a third party library allows for evolution until a stable state is reached before starting to introduce breaking changes in the standard library.
