On Thursday, 6 February 2014 at 19:24:39 UTC, Sean Kelly wrote:
> On Wednesday, 5 February 2014 at 20:37:44 UTC, Sean Kelly wrote:
>>
> https://github.com/D-Programming-Language/phobos/pull/1910

Hello,

I have a little question about how pre-emption works with the FiberScheduler. Let's say I create 100.000 fibers that all run long-runners (such as calculating fibonacci(100)). Now I start another fiber that just prints "hello world" to the console. So it's a short runner. When can I expect "hello world" to appear on the console?

a. Will take a long time in case fibonacci(100) never does any yield.
b. The FiberScheduler will do a yield periodically. So "hello world" will be displayed in not so long time
c. I need to do a yield from within the fibonacci function here and then for "hello world" to be displayed in not so long time

Just for my understanding ...
Thanks, Bienlein

On Thursday, 13 February 2014 at 15:30:58 UTC, Bienlein wrote:
> On Thursday, 6 February 2014 at 19:24:39 UTC, Sean Kelly wrote:
>> On Wednesday, 5 February 2014 at 20:37:44 UTC, Sean Kelly wrote:
>>>
>> https://github.com/D-Programming-Language/phobos/pull/1910
>
> Hello,
>
> I have a little question about how pre-emption works with the FiberScheduler. Let's say I create 100.000 fibers that all run long-runners (such as calculating fibonacci(100)). Now I start another fiber that just prints "hello world" to the console. So it's a short runner. When can I expect "hello world" to appear on the console?

The API is able to context switch inside send and receive. So if you aren't sending messages with some frequency then the level of parallel execution will be fairly low.  For apps like this, it's possible that a more complex scheduler that is backed by a thread pool would be more appropriate.  Since D isn't built from the ground up around fibers, choosing the right scheduler for your application is an important decision.

On Thursday, 13 February 2014 at 15:40:05 UTC, Sean Kelly wrote:
> The API is able to context switch inside send and receive. So if you aren't sending messages with some frequency then the level of parallel execution will be fairly low.  For apps like this, it's possible that a more complex scheduler that is backed by a thread pool would be more appropriate.  Since D isn't built from the ground up around fibers, choosing the right scheduler for your application is an important decision.

Hi Sean,

thanks for the quick reply. Let's say I have most of my actors running with the FiberScheduler. Then I have my emergency actor that is supposed to run down my nuclear power plant here and now in case it receives a message to do so. Now I let the emergency actor run in a kernel thread. This way it should be able to be immediately responsive. Is that right? Because that would be really good enough for me.

Thanks, Bienlein

Yes. The schedulers are required to maintain some data (one being a message queue) for each "thread" they spawn. If the data is requested from a thread the scheduler doesn't own, it's required to return a thread-local copy instead. In short, any manually created kernel thread will get its own message queue regardless of the scheduler in place.

Am Tue, 04 Feb 2014 10:43:26 -0800
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> On 2/4/14, 10:05 AM, Sean Kelly wrote:
> > Support for green threads in std.concurrency is almost complete. I should really just do the last bit of work. I imagine you could try out the idea now though by using the messaging in vibe.d, since every connection is a fiber.
> 
> Did you express that work as one or more bugzilla issues?
> 
> Andrei

As in: "This would make a good change log entry for added features" ?

-- 
Marco

On Thursday, 13 February 2014 at 15:40:05 UTC, Sean Kelly wrote:
> On Thursday, 13 February 2014 at 15:30:58 UTC, Bienlein wrote:
>> On Thursday, 6 February 2014 at 19:24:39 UTC, Sean Kelly wrote:
>>> On Wednesday, 5 February 2014 at 20:37:44 UTC, Sean Kelly wrote:
>>>>
>>> https://github.com/D-Programming-Language/phobos/pull/1910

Are there some plans when we will have the FiberScheduler be included in D? Wait for D 2.066? Not wanting to be "pushy", it's only because of pure impatience ;-)

Am 03.03.2014 11:31, schrieb Bienlein:
> On Thursday, 13 February 2014 at 15:40:05 UTC, Sean Kelly wrote:
>> On Thursday, 13 February 2014 at 15:30:58 UTC, Bienlein wrote:
>>> On Thursday, 6 February 2014 at 19:24:39 UTC, Sean Kelly wrote:
>>>> On Wednesday, 5 February 2014 at 20:37:44 UTC, Sean Kelly wrote:
>>>>>
>>>> https://github.com/D-Programming-Language/phobos/pull/1910
>
> Are there some plans when we will have the FiberScheduler be included in
> D? Wait for D 2.066? Not wanting to be "pushy", it's only because of
> pure impatience ;-)

Just out of curiosity, what did you miss in vibe.d regarding fiber based scheduling?

Of course it would be great to have something like this in Phobos, but to really have a consistent system, changes need to be made all over the place to make things work asynchronously under the hood, or you have a system that makes it really easy to shoot yourself in the foot, which may be much worse than not having support at all. Rather than starting with bits of this here and there, the complete picture should IMO be well though out beforehand, and rather be started by integrating low level asynchronous operations (and a pluggable event loop implementation). Adding fiber based concurrency would then be the last step.

On Monday, 3 March 2014 at 14:27:53 UTC, Sönke Ludwig wrote:
>
> Just out of curiosity, what did you miss in vibe.d regarding fiber based scheduling?

Hi Söhnke,

I'm thinking of developing a little actor library on top of D's spawn/receive model for creating threads, which is already actor-like but on a level of global functions. I want to mold some thin class layer on top of it to have actors on class level. Vibe.d would be a good solution for distributed actors. But for a first step I want to have local actors. Actors that are in the same memory space don't need to communicate through sockets as in case of vibe.d.

Regards, Bienlein

On Monday, 3 March 2014 at 14:27:53 UTC, Sönke Ludwig wrote:

> Just out of curiosity, what did you miss in vibe.d regarding fiber based scheduling?

There is something else I forgot to mention. One scenario I'm thinking of is to have a large number of connections like more than 100.000 I want to listen on. This results in a situation with blocking I/O for all those connections. Fibers in D are more like continuations that are distributed over several kernel threads. The way Sean Kelly has implemented the FiberScheduler a fiber is invoked in case it receives an item like data through the connection it serves as in my scenario. At least this is the way I understood the implementation. So I can have like 100.000 connections simultanously as in Go without having to use Go (the Go language is too simple for my taste).

On Monday, 3 March 2014 at 14:27:53 UTC, Sönke Ludwig wrote:

> Just out of curiosity, what did you miss in vibe.d regarding fiber based scheduling?

By the way is there a way to make use of vibe.d in something like a local mode? I mean some in-memory mode without going through TCP.

Thanks, Bienlein