Swift Embedded Concurrency

Hello!
I read in the Swift Embedded manual that Swift Concurrency is under development.

This got me wondering... How is this going to be implemented? For example, will we provide some sort of callbacks representative of each thread to the concurrency API?

1 Like

We are currently working through "How is this going to be implemented", so the answer for now is to stay posted.

One active area of work is stabilizing the interface between libSwiftConcurrency and the "Executor" which actually runs the Swift Concurrency Tasks. On desktop platforms, this is handled by libDispatch, but on embedded systems it will need a different library specific to the platform.

its likely we will need to create adapters for popular runtimes e.g. Zephyr, FreeRTOS, etc...

4 Likes

Just curious, anything happening here in nightly builds or branches that I could play with?

Not yet, no. Weā€™ll have to propose some APIs through swift evolution and once we have a direction in mind this will be shared through the usual evolution pitches and process. Thereā€™s nothing early to check out yet, you can probably keep an eyes on this thread for any movement. Itā€™s just a bit too early to share the ideation phases.

2 Likes

Does this relate to a potential different backend also for normal Linux as mention here by @ktoso / @John_McCall ?

If you have an actually concurrent embedded environment, it would probably be easier to port a new thread pool to your environmentā€™s thread system than to port all of libdispatch. A lot of embedded environments are not concurrent in the threads sense, though ā€” they might take asynchronous signals/interrupts, which is a form of concurrency, but thereā€™s no actual parallel execution.

Right, let me clarify: I was more curious if this work dovetailed with the possible replacement of libdispatch on Linux with a custom thread pool - we see a number of performance issues weā€™d like to try to help sort out on Linux that are related to libdispatch but as itā€™s not the long term solution weā€™re curious whether the work for embedded would define the required apis for us to roll our own runtime then if needed more easily.

Ah. I donā€™t think the possible Dispatch replacement has much to do with it, but yes, if you want to completely swap out the thread pool, that is something embedded developers also want to do and should become easier as part of this work.

2 Likes

I'm completely resigned to rolling my own support over something like Zephyr, and am actually quite interested in seeing what that looks like. Just not sure which of the concurrency abstractions I should be paying attention to beyond Executor (which seems a bit light as an abstraction for this).

Chiming in to follow this as, I want to port IORingSwift to Zephyr. And maybe Swift to XMOS, although that might be a bit too ambitious a distraction.