Resumable function based device drivers and fibers

[chris-durand]

Hi everyone,

we have tons of resumable function based device drivers, but have introduced fibers as our shiny new alternative concurrency mechanism. I was asking myself if it would be possible to implement a compatibility layer to use our present drivers without protothreads but with fibers.

Couldn't we just implement the resumable function macros in terms of fibers? RF_WAIT_WHILE(x) would become while (x) modm::fiber::yield();. RF_BEGIN/_END would be no-ops, RF_RETURN(x) is just return x;, etc.

Do you think that could work or am I overlooking something?

@salkinium

[salkinium]

Yes exactly, I think it would work without mayor problems.
Since the yield() returns immediately if no fiber is running, RF_CALL_BLOCKING works too, but multiple protothreads may now stall if called inside the main function. So ideally each protothread becomes a fiber with it's own default stack, which could be done automatically via inheritance and a member uint8_t stack[default_size]; and running the update/run function by default. Not super smooth, but at least it's only an application problem, the resumable functions should work fine.

[salkinium]

This was finally implemented in #1001.

[rasmuskleist]

This sounds quite interesting to me as we still have an unresolved issue in our own project, which is being discussed in #893. Specifically, we want to use a third-party filesystem for a NOR flash with resumable calls to the block device. Is the discussion of resumable function macros in terms of fibres still relevant and what is the outlook? I will happily contribute to this development!

[salkinium]

Yes, it is, just haven't gotten there yet. My plan for the near future is:

1. Make the fibers visible (remove the modm:__fibers repo option). They are completely functional, just lack communication primitives (ie. semaphores/mutes/queues), but that's no different than the Protothreads right now. They won't get improved if they're not used.
2. Turn the peripheral drivers into fibers (ie. add the modm::fiber::yield() in the right place). This is the most important step.
3. Make the Protothread/Resumable Macros compatible with fibers.
4. Rewrite the drivers to remove protothreads/resumables where needed. It's probably not that difficult, can perhaps even be done by regex substitution.

[salkinium]

In the medium term future it would be nice to have a smarter scheduler than a round robin one. That requires support for signalling events (for example, when a peripheral driver is finished and needs to wake up the fiber again).
However, it would be nice to do this in a smarter, more lightweight way than a traditional RTOS (ie. specifically not just copying semaphores), because there are already enough of those around.

In the long term future, it would be nice to have the fibers somehow compatible with preemptive threads like FreeRTOS.
That would probably require something like a local event loop that is arbitrated by message queues, kinda like Qt's buffered signal/slot connections. That way you can still use very lightweight fibers on AVR, but an actual RTOS on a fast Cortex-M device.

[salkinium]

Ok, so I implemented the drop-in replacement Protothread/Resumable implementation here: #1001. Still needs more work, but the hack does work.

[rasmuskleist]

Thanks for the quick reply! I will be looking through the pull request today. Please let me know if I can contribute anything.

[salkinium]

I think it would help to know that this actually solves your problem, cos the implementation right now is a bit clunky and we probably missed a few use-cases. The Fiber/Scheduler class APIs will definitely have to change a little, so it would be good to make all the breaking changes in one go.