"Spawn as many thousand threads as you like" and D

[Sönke Ludwig via Digitalmars-d]

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.