I'm intrested in fibers and async io.
Could anyone suggest articles, books or tutorials about the subject?

Thank you

On 04/23/2015 06:56 AM, ref2401 wrote:
> I'm intrested in fibers and async io.
> Could anyone suggest articles, books or tutorials about the subject?
>
> Thank you

I am working on adding a Fibers chapter to my book. Although it is still a draft and not linked from any other page, I've made it online:

  http://ddili.org/ders/d.en/fibers.html

I appreciate any feedback before the book is finally printed sometime before DConf.

Thank you,
Ali

Awesome!

On Thursday, 23 April 2015 at 14:22:01 UTC, Ali Çehreli wrote:
> On 04/23/2015 06:56 AM, ref2401 wrote:
>   http://ddili.org/ders/d.en/fibers.html
>
> I appreciate any feedback before the book is finally printed sometime before DConf.

This is great information. I didn't know anything about Fibers before today.
Since I started looking at D, I've seen many new and innovative ways of programming.
Fibers are definitely also beneficial for microcontrollers.
I can think of a few things that would make good use of Fibers:
1: Real-time Video decompression.
2: File decompression in general.
3: Audio mixing and playback (eg. a MOD player for instance).
4: Collecting data from external devices and sensors.
5: Queueing up a bunch of different jobs; for instance copying files (everyone probably knows by now not to start copying files if already copying files).

... Thinking a bit further, I've sometimes wanted to make multiple cores work on fetching jobs from the same queue. Would Fibers be good for spreading out jobs this way?
Actually, it would be neat to have a class, which could manage job-dependencies, so that all CPUs could be made busy without having to make things look complicated. Someone probably made this already, though. ;)

On Thursday, 23 April 2015 at 16:57:30 UTC, Jens Bauer wrote:
> On Thursday, 23 April 2015 at 14:22:01 UTC, Ali Çehreli wrote:
>> On 04/23/2015 06:56 AM, ref2401 wrote:
>>  http://ddili.org/ders/d.en/fibers.html
>>
>> I appreciate any feedback before the book is finally printed sometime before DConf.
>
> This is great information. I didn't know anything about Fibers before today.
> Since I started looking at D, I've seen many new and innovative ways of programming.
> Fibers are definitely also beneficial for microcontrollers.
> I can think of a few things that would make good use of Fibers:
> 1: Real-time Video decompression.
> 2: File decompression in general.
> 3: Audio mixing and playback (eg. a MOD player for instance).
> 4: Collecting data from external devices and sensors.
> 5: Queueing up a bunch of different jobs; for instance copying files (everyone probably knows by now not to start copying files if already copying files).
>
> ... Thinking a bit further, I've sometimes wanted to make multiple cores work on fetching jobs from the same queue. Would Fibers be good for spreading out jobs this way?
> Actually, it would be neat to have a class, which could manage job-dependencies, so that all CPUs could be made busy without having to make things look complicated. Someone probably made this already, though. ;)

At the moment I'm using threads to implement a speech synthesizer. It waits for input, synthesizes it, and then "speaks" in a separate thread. If new input comes, the speaking thread is stopped. I wonder, if fibers would be a viable alternative to threads (after all audio playback was mentioned in the list above).

On Thursday, 23 April 2015 at 19:24:31 UTC, Chris wrote:
> On Thursday, 23 April 2015 at 16:57:30 UTC, Jens Bauer wrote:
>> 3: Audio mixing and playback (eg. a MOD player for instance).
>> 5: Queueing up a bunch of different jobs;
>
> At the moment I'm using threads to implement a speech synthesizer. It waits for input, synthesizes it, and then "speaks" in a separate thread. If new input comes, the speaking thread is stopped. I wonder, if fibers would be a viable alternative to threads (after all audio playback was mentioned in the list above).

I'll try and give you some (perhaps useless) input... :)

I think there are a number of good possibilities for spreading out the jobs.
First thought is to split every job on spaces; eg. every word is a separate job, some words may be possible to "recycle" either fully or partly, depending on how they're pronounced in the particular context.
I cannot give any conclusions, but I do see that ...
Using multiple CPU cores with each their own Fiber would probably be the most optimal solution. Each Fiber could perhaps synthesize a word at a time.
-But I do not know if you're able to control which core your Fiber is running on.

That would of course only generate the data (faster than real-time on most systems).
An audio frame-buffer interrupt could 'pull' the data, when necessary. Such an interrupt could also mix multiple voices (having different/variable volume and panning) if needed (here I'm thinking of 'speaking' the conversations in a chat-room).

On Thursday, 23 April 2015 at 22:26:28 UTC, Jens Bauer wrote:
> On Thursday, 23 April 2015 at 19:24:31 UTC, Chris wrote:
>> On Thursday, 23 April 2015 at 16:57:30 UTC, Jens Bauer wrote:
>>> 3: Audio mixing and playback (eg. a MOD player for instance).
>>> 5: Queueing up a bunch of different jobs;
>>
>> At the moment I'm using threads to implement a speech synthesizer. It waits for input, synthesizes it, and then "speaks" in a separate thread. If new input comes, the speaking thread is stopped. I wonder, if fibers would be a viable alternative to threads (after all audio playback was mentioned in the list above).
>
> I'll try and give you some (perhaps useless) input... :)
>
> I think there are a number of good possibilities for spreading out the jobs.
> First thought is to split every job on spaces; eg. every word is a separate job, some words may be possible to "recycle" either fully or partly, depending on how they're pronounced in the particular context.
> I cannot give any conclusions, but I do see that ...
> Using multiple CPU cores with each their own Fiber would probably be the most optimal solution. Each Fiber could perhaps synthesize a word at a time.
> -But I do not know if you're able to control which core your Fiber is running on.
>
> That would of course only generate the data (faster than real-time on most systems).
> An audio frame-buffer interrupt could 'pull' the data, when necessary. Such an interrupt could also mix multiple voices (having different/variable volume and panning) if needed (here I'm thinking of 'speaking' the conversations in a chat-room).

I was more thinking of the audio thread. But the audio is probably better off in a separate thread.

On Friday, 24 April 2015 at 09:15:21 UTC, Chris wrote:
>
> I was more thinking of the audio thread. But the audio is probably better off in a separate thread.

I think you could do this too.
In fact, this is very similar to how the audio from a MOD file is decoded.
(I only mentioned an interrupt, because I'm used to putting audio in interrupts, since I work very close to the hardware; meaning that interrupts will normally be much more efficient)

On Friday, 24 April 2015 at 12:38:39 UTC, Jens Bauer wrote:
> On Friday, 24 April 2015 at 09:15:21 UTC, Chris wrote:
>>
>> I was more thinking of the audio thread. But the audio is probably better off in a separate thread.
>
> I think you could do this too.
> In fact, this is very similar to how the audio from a MOD file is decoded.
> (I only mentioned an interrupt, because I'm used to putting audio in interrupts, since I work very close to the hardware; meaning that interrupts will normally be much more efficient)

I might give it a shot.