-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The go! macro is unsound #109
Comments
This is designed intentially. If you need to make unsafe block explicitly, you could use the raw spawn API directcly. |
That's not how |
Hi, I just saw caveats, and became curious, so here I ask. can we detect when accessing the TLS in coroutine? If so, what about just |
I encountered this issue sir. Here's the code I used. The first code using V8 engine :
The second code using JS Core engine
The code above doesn't execute the |
The
go!
macro is unsound and should require anunsafe
block to use, with proper "Safety" documentation for the macro.As discussed in #6, this crate can be unsound when thread-local storage is used. My understanding is that this is an unavoidable property of stackful coroutines when there isn't language-level support for them. Nonetheless, APIs that can lead to UB should only be accessible within an
unsafe
block and have documentation for the conditions under which their use is sound (that's whatunsafe
is for).In #8 the
spawn
API was correctly marked asunsafe
because of this. However, then thego!
macro was introduced which simply silently inserts theunsafe
block -- this only serves to hide the issue from users and obscure the safety documentation.Personally, I'd remove the
go!
macro altogether. But if it is to stay, then I think it should definitely require anunsafe
block and its safety requirements should be properly documented as anyunsafe
function should.The text was updated successfully, but these errors were encountered: