A scheduled control signal with fibers?

[Steven Schveighoffer]

On 9/25/20 9:16 AM, Ferhat Kurtulmuş wrote:
> On Friday, 25 September 2020 at 13:08:16 UTC, Sebastiaan Koppe wrote:
>> On Friday, 25 September 2020 at 11:58:53 UTC, Ferhat Kurtulmuş wrote:
>>> [...]
>>
>> No need for fibers per se.
>>
>> You can run 2 threads. One that produces {time: now + 1500.msecs, 
>> value: getFlameIntensityViaImageProcessing} objects and one that 
>> consumes those and basically waits until each's msg.time < now and 
>> then sendPWMSignalToValfe(msg.value). You would basically rely on 
>> std.concurrency's MessageBox to do the queuing. Although you could do 
>> that manually as well.
>>
>> Could also run it on 1 thread if you don't mind there being a jitter 
>> of however long getFlameIntensityViaImageProcessing takes, but you 
>> will need a queue.
> 
> That was the first thing I thought. A FIFO queue. I just wanted to not 
> reinvent the wheel. So, you guys say go for regular threads not fibers. 
> Thank you.

Whether a fiber is a valid solution or not depends on that 
getFlameItensityViaImageProcessing function.

If that is actually code running in your process, a fiber is going to 
block any other fibers during that operation. So threads are the way to 
go here.

fibers work great if you can yield the fiber when waiting on something 
*external* to complete (like for instance, i/o). But if the fiber *is* 
the thing you are waiting on, it's not going to be able to execute 
anything else until that is done.

Given the rate and the number of concurrent tasks, I'd say threads.

-Steve