Swift standard library on platforms without threading support?


(Max Desiatov) #1

I'm very interested know if there's an easy way to get existing Swift standard library working on platforms that don't support threading, like AVR and WebAssembly.

From what I saw in the standard library and runtime source code, there's a strong assumption of threading support in stdlib, e.g. all reference counting code relies on working <atomic> header, which can't be imported on platforms without threading:

#error <atomic> is not supported on this single threaded system

Maybe someone have already done some work to port the standard library and runtime to an environment without threading support or maybe there's some preprocessor or build script configuration flag that I missed?


(Amir Abbas Mousavian) #2

I'm not a developer of Swift or stdlib but I think there is a good chance that move-only types proposed for Swift 5 would solve this issue.

(Joe Groff) #3

@carlos4242 has been working on an alternative standard library implementation for AVR:

It would be interesting to add a configuration flag to disable threading support in the "normal" runtime and standard library. Nobody's done that yet to my knowledge. For that specific issue, though, it is incorrect to avoid using <atomic> in a single-threaded system; I'm not sure why that #if is there. <atomic> is still meaningful for a single-threaded system for atomicity relative to signals and other preemption mechanisms.


As far as I understand move only types will not be introduced with Swift 5, there is no such proposal, but there is consensus that they should come eventually someday and somehow. Current proposals that mention and are motivated by the introduction of move only types aim to avoid post Swift 5 ABI breakage, when they really become an issue…

(Joe Groff) #5

Move-only types won't impact whether the runtime needs to be thread safe on multithreaded platforms.

(Carl Peto) #6

My uStdlib is very, very basic and is almost more of a research project than anything else. I'm very happy to share what I have and the progress/thoughts I'm making but I'm wondering where is best to put it? It's not production ready in any way (and may never be any time soon). Also it's currently fairly heavily slanted to the sort of things i personally want in my AVR code.

What would be a good way to share it?

(The 16 bit pointer fixes for the compiler will come as a separate PR which I think will be mergeable. The PR for AVR support on it's own will be a different patch!)

(Max Desiatov) #7

Well, that's what libcxx has there at the moment ¯\_(ツ)_/¯

I'm not quite sure though if signals make any sense on WebAssembly or AVR, especially if programs for the latter are supposed to run on bare metal?

What would be the best approach for this then? My initial plan was to do something like

#ifndef __wasm__ 
#include <atomic> 

in Swift runtime headers and to reimplement all users of <atomic> with a nonatomic #ifdefed version? Or maybe it's worth implementing something like SingleThreadedAtomic.{h,cpp} that would stub all required atomic primitives with single-threaded "no-op" implementation?

(Joe Groff) #8

I’m not familiar enough with wasm, but on bare metal hardware platforms, interrupts could still be a concern. It’s unfortunate libc++ doesn’t have a single-threaded atomic implementation, but having a stubbed-out version of atomic, mutex, and other synchronization primitives would be nice to minimize the amount of conditional code we need in the runtime itself.