I'm writing a suspend function but it's not safe t...
# coroutines
d
I'm writing a suspend function but it's not safe to call concurrently. Usually one would call this method "Not thread safe" but in the coroutine world what do you call this? "Not coroutine safe"? Sounds weird.
l
Technically it's still "not thread safe" given that the underlying concurrency is threads?
a
Hm, interesting. I would definitely not call it “Not coroutine safe” as it is strange indeed for a coroutine-driven function 🙂 Probably something verbose like “Not safe for concurrent execution” is clearer. If the underlying logic is not thread-safe (e.g. accessing mutable collection), then “Not thread safe” is still a good term.
a
"should not be called concurrently with itself" is phrasing I've used before
d
The underlying logic is basically CAS without atomics and a http call. Was hoping for a nice term but I guess I'm stuck with a sentence for now.
j
Can you shove a Mutex inside it? That's what I'm doing in Rust when talking to hardware that's async but cannot be used concurrently
Unless it's extremely high performance code, better to not have the caller have to worry about it
3
a
If you don’t have suspension points within your CAS operation then it seems like you can safely call it “concurrently” within the same thread. Thus term “Not thread safe” should work fine (e.g. one could use single thread dispatcher instead of Mutex).
d
I could stick a mutex in but the API isn't in it's final shape so I'm being lazy. I don't expect users to want to call the method concurrently anyway.
The suspension point is the http call.
k
Why do you need to stick the mutex in the API? Why can't it be an implementation detail?
u
Is it "not reentrant"?
l
You don't need reentrant mutex for that use case. Have a private top level one, and use
withLock
u
I mean his code is not reentrant. @Dominaezzz was looking for a better term than "not threadsafe"
d
Took me a while to understand what "not reentrant" meant outside the context of mutexes. Seems a bit too low-level to be useful.
j
You can only be reentrant if there's some kind of callback though
u
Our equivalently a suspension point
☝🏼 1
l
You mean a suspending callback, right?
🙂 1
a
you could consider suspension as similar to the C/interrupt handler usage of the term but it's a bit of a stretch, and since suspend and multithreading show up together so often, speaking to reentrance alone probably won't be sufficient to help people understand the expectation
u
Yes. I mean reentrant as "can safely be reentered while still executing"
My thinking was, calling it not thread safe could lead people to think it is ok to execute on a single threadded dispatcher