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
