On 05/21/2013 10:22 AM, Jack Moffitt wrote:
AFAIK that's not supposed to happen if task A checks errno (or other
thread-local value) immediately after returning from the failed call. Tasks
are switched cooperatively within the scheduler thread.
Those semantics are true I think, and I believe will remain true, but
they are not obvious. Hopefully this will get documented. The docs for
the core::os calls should probably mention that you have to check
errno without doing any intermediate I/O.
Oh, yeah I/O is a good one to point out. It's not currently the case
that I/O will deschedule your task, but it will be in the future.
What are the task switch boundaries? Is it just I/O? Or can
non-inlined function calls also cause switches (this is for example
where Erlang code replacement is allowed to happen). There's no way to
know if some function does I/O transitively, so predicting task
switches is not necessarily trivial.
Currently tasks yield primarily on pipe sends and receives, but there
are also a some other synchronization types in std that yield.
How often is this pattern used in C code? Are there other examples
where thread-local storage is used for library state?
jack.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
