Signal safe Swift concurrency

Using Swift
1

Hi,

I've been learning more about Swift concurrency and it's great to see all the ways it can help avoid typical race conditions. One kind of race condition that I run into a lot is related to reentrancy and signal handling. Definitely not a "typical" race conditions, but I have some projects that use mach exception handlers and others like ETTrace (GitHub - EmergeTools/ETTrace: Easily and accurately profile iOS apps) that need to pause threads with thread_suspend. These can only use async signal safe functions and a few times I've hit issues that cause deadlock from using unsafe operations in these sections of code. Particularly heap allocations, which is one issue in ETTrace I'm working on now.

I was curious if Swift concurrency has any plans to help with these kinds of race conditions? Is there any compiler feature with Swift concurrency that can guard against non signal safe code being used in these cases? I think it's not safe to use any Swift code when signal safety is required due to heap allocations being unsafe, but curious if there is anything else I could be doing to leverage Swift concurrency here or any plans to support these use cases?

Thanks!

3 Likes
2

Is there any compiler feature with Swift concurrency that can
guard against non signal safe code being used in these cases?

I don’t really see this being part of Swift concurrency. The concurrency runtime is intimately tied to threads and memory, and it’d be hard to separate those.

There is an effort to make Swift work in contexts where allocating memory and taking locks is not allowed. However, this is centred on synchronous functions, in constrast to the asynchronous functions supported by Swift concurrency. Your entry point to this should be the @_noAllocation and @_noLocks attributes mentioned here.

IMPORTANT The leading underscore means that this isn’t officially part of the language.

I don’t have any special insight into these myself. Right now I’m just a curious bystander. [1] If you really want this, you could wade into Swift Evolution.

Share and Enjoy

Quinn “The Eskimo!” @ DTS @ Apple

[1] If and when this all becomes official, I might need to update Implementing Your Own Crash Reporter.

4 Likes
3

Please keep us posted, that sounds pretty interesting.

4

that sounds pretty interesting.

Yep.

Please keep us posted,

I’m not in a privileged position here. I learn about this the same way you folks do, by lurking on Swift Evolution.

Share and Enjoy

Quinn “The Eskimo!” @ DTS @ Apple

1 Like
5

Thanks @eskimo the @_noLocks attribute is perfect for my use case, I started using it in my project and was able to find where I was unintentionally calling runtime functions that were not safe to use from my signal handler!

2 Likes