-
Notifications
You must be signed in to change notification settings - Fork 19
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
Remove unsound ScopedCoroutine #28
Conversation
This is unsound because it allows values on the stack to be forgotten without running their associated drop code, which is unsound for constructs like scoped threads. Fixes #27
/// A coroutine wraps a closure and allows suspending its execution more than | ||
/// once, returning a value each time. | ||
/// | ||
/// # Dropping a coroutine | ||
/// | ||
/// When a coroutine is dropped, its stack must be unwound so that all object on | ||
/// it are properly dropped. This is done by calling `force_unwind` to unwind | ||
/// the stack. If `force_unwind` fails then the program is aborted. | ||
/// | ||
/// See the [`Coroutine::force_unwind`] function for more details. | ||
/// | ||
/// # `Send` | ||
/// | ||
/// In the general case, a coroutine can only be sent to another if all of the | ||
/// data on its stack is `Send`. There is no way to guarantee this using Rust | ||
/// language features so `Coroutine` does not implement the `Send` trait. | ||
/// | ||
/// However if all of the code executed by a coroutine is under your control and | ||
/// you can ensure that all types on the stack when a coroutine is suspended | ||
/// are `Send` then it is safe to manually implement `Send` for a coroutine. | ||
#[cfg(not(feature = "default-stack"))] | ||
pub struct Coroutine<Input, Yield, Return, Stack: stack::Stack> { | ||
stack: Stack, | ||
stack_ptr: Option<StackPointer>, | ||
initial_stack_ptr: StackPointer, | ||
drop_fn: unsafe fn(ptr: *mut u8), | ||
marker: PhantomData<fn(Input) -> CoroutineResult<Yield, Return>>, | ||
marker2: PhantomData<*mut ()>, | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use type alias to avoid duplicate definitions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because it makes the documentation look better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is #[doc(inline)]
attribute in case you want the underlying definition to pop up in the documentation. Anyway, what's done is done.
This is unsound because it allows values on the stack to be forgotten without running their associated drop code, which is unsound for constructs like scoped threads.
Fixes #27