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");
> }
>

BTW, thank you for explaining the background, I think you were right that the focus is far too strong on the network part of the library, which can definitely be misleading (it was more appropriate two years ago, when most of this was written). I've taken the opportunity and updated a few pages to mention the non-I/O primitives and added a paragraph clarifying the use of yield:

> All of this usually happens behind the curtain of the vibe.d API, so that everything feels like just working with normal threads and blocking operations. All blocking functions, such as sleep() or read() will yield execution whenever they need to wait for an event and let themselves resume when the event occurs.

Am 16.04.2014 20:34, schrieb Russel Winder via Digitalmars-d:
> On Wed, 2014-04-16 at 16:06 +0200, Sönke Ludwig via Digitalmars-d wrote:
> […]
>>
>> I agree, but I also wonder why you still keep ignoring vibe.d. It
>> achieves exactly that - right now! Integration with std.concurrency
>> would be great, but at least for now it has an API compatible
>> replacement that can be merged later when Sean's pull request is done.
>
> Vibe.d is a single-thread event system, which is great (*) for the sort
> of problems Node.js, Vert.x, Tornado, Flask, Sinatra, Ratpack are used
> for. The point here is that CSP and dataflow are a concurrency and
> parallelism model that D has not got.

I agree that those would be nice to have, but I think the main point was more about having transparent "green threads" than the actual concurrency model (at least that was the point that was itching me ;)

>
> std.concurrency is a heavyweight thread system so not really useful
> except to build thread pools and fork-join infrastructure. (OK that is a
> gross oversimplification.) std.parallelism is a great beginning of data
> parallelism on a thread pool. It needs more work. The thread pool needs
> to be brought front and centre, as a separate thing usable by other
> modules. On this CSP, dataflow, actors, etc. can be built.

At least the infrastructure part is pretty much in place for vibe.d when using worker tasks [1]. The tasks are getting distributed among a set of worker threads and fibers (fibers are getting reused for efficiency), so that spawning tasks is a very light-weight operation.

>
> Due to other commitments, not least leading a massive update of GPars, I
> cannot lead on working on D things. If however someone can drive, I will
> certainly contribute, along the lines as I did when David Simcha wrote
> std.parallelism – mostly as a tester and reviewer.
>
> This also raises the issue of the D infrastructure having an obvious and
> documented way for people to contribute to things like std.parallelism.
> Whatever the truth, the perception is that to work on something like
> std.parallelism, you have to fork the whole of Phobos. In fact,
> std.parallelism is a single file 4,500 lines long (**).
>
>
> (*) It would be even better if it supported mocking for unit tests ;-)

Absolutely, that's an issue I'm stumbling over every now and then for some parts of the code. The only issue is that it would need to be integrated in a way that doesn't make methods needlessly virtual (using interfaces everywhere) and doesn't break the API (using templates everywhere).

>
> (**) I am still not a fan of single files this big.
>

(I actually hate this. I like to have a mental model of the source code I'm working on. But for Phobos code the only possibility is usually to stab at local parts found via a full text search, which always leaves a bad taste when making changes due to the unknown implications. A proper hierarchical organization with defined dependencies could work wonders there.)

[1]: http://vibed.org/api/vibe.core.core/runWorkerTask

> 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.

Hello Sönke,

would it be possible in vibe.d to spawn a task the usual actor-style way as it is done with kernel threads in D? What I mean is this:

void spawnedFunc(Tid tid)
{
   receive(
     (int i) { writeln("Received the number ", i);}
   );

}

auto tid = spawn(&spawnedFunc, thisTid);


Thanks, Bienlein

Am 07.05.2014 17:28, schrieb Bienlein:
>
> Hello Sönke,
>
> would it be possible in vibe.d to spawn a task the usual actor-style way
> as it is done with kernel threads in D? What I mean is this:
>
> void spawnedFunc(Tid tid)
> {
>     receive(
>       (int i) { writeln("Received the number ", i);}
>     );
>
> }
>
> auto tid = spawn(&spawnedFunc, thisTid);
>
>
> Thanks, Bienlein

The Tid handling is currently a little different, but apart from that it should work like this:

	import vibe.core.core;
	import vibe.core.concurrency;

	void spawnedFunc(Tid tid)
	{
	    receive(
	      (int i) { writeln("Received the number ", i); }
	    );
	}

	// run it as a fiber in the same thread
	// note: runTask only takes a delegate to make runTask({ ... })
	// work without an ambiguity error
	auto tid = runTask(toDelegate(&spawnedFunc), Task.getThis());

	// or run it in the thread pool instead
	runWorkerTask(&spawnedFunc, Task.getThis());

Having said that, I'll just add a "thisTid" property to vibe.core.concurrency to make that part API compatible. I'd also add a "spawn" alias, but the question is if that should point to runTask or rather to runWorkerTask.

Am 07.05.2014 19:06, schrieb Sönke Ludwig:
> Am 07.05.2014 17:28, schrieb Bienlein:
>>
>> Hello Sönke,
>>
>> would it be possible in vibe.d to spawn a task the usual actor-style way
>> as it is done with kernel threads in D? What I mean is this:
>>
>> void spawnedFunc(Tid tid)
>> {
>>     receive(
>>       (int i) { writeln("Received the number ", i);}
>>     );
>>
>> }
>>
>> auto tid = spawn(&spawnedFunc, thisTid);
>>
>>
>> Thanks, Bienlein
>
> The Tid handling is currently a little different, but apart from that it
> should work like this:
>
>      import vibe.core.core;
>      import vibe.core.concurrency;
>
>      void spawnedFunc(Tid tid)
>      {
>          receive(
>            (int i) { writeln("Received the number ", i); }
>          );
>      }
>
>      // run it as a fiber in the same thread
>      // note: runTask only takes a delegate to make runTask({ ... })
>      // work without an ambiguity error
>      auto tid = runTask(toDelegate(&spawnedFunc), Task.getThis());
>
>      // or run it in the thread pool instead
>      runWorkerTask(&spawnedFunc, Task.getThis());
>
> Having said that, I'll just add a "thisTid" property to
> vibe.core.concurrency to make that part API compatible. I'd also add a
> "spawn" alias, but the question is if that should point to runTask or
> rather to runWorkerTask.


BTW, a runnable example can be found here:
https://github.com/rejectedsoftware/vibe.d/blob/master/examples/message/source/app.d

On Wednesday, 7 May 2014 at 17:13:07 UTC, Sönke Ludwig wrote:

>> The Tid handling is currently a little different, but apart from that it
>> should work like this:
>>
>>     import vibe.core.core;
>>     import vibe.core.concurrency;
>>
>>     void spawnedFunc(Tid tid)
>>     {
>>         receive(
>>           (int i) { writeln("Received the number ", i); }
>>         );
>>     }
>>
>>     // run it as a fiber in the same thread
>>     // note: runTask only takes a delegate to make runTask({ ... })
>>     // work without an ambiguity error
>>     auto tid = runTask(toDelegate(&spawnedFunc), Task.getThis());
>>
>>     // or run it in the thread pool instead
>>     runWorkerTask(&spawnedFunc, Task.getThis());
>>
>> Having said that, I'll just add a "thisTid" property to
>> vibe.core.concurrency to make that part API compatible. I'd also add a
>> "spawn" alias, but the question is if that should point to runTask or
>> rather to runWorkerTask.
>
>
> BTW, a runnable example can be found here:
> https://github.com/rejectedsoftware/vibe.d/blob/master/examples/message/source/app.d

Thanks for the quick answer. I'll give it a try ;-).