On 05/21/2013 06:35 AM, [email protected] wrote:
Sorry to disturb the thread with many messages. I feel I have to
provide details to my question
In POSIX programming, calling errno is thread-safe in the following sense
1. Thread A makes some system call X, and the call fails
2. Meanwhile, Thread B makes some system call Y. This call also fails
3. Thread A checks its errno. The errno indicates the reason of
failure of call X
4. Thread B also checks its errno. The errno indicates the failure of
call Y
The above is guaranteed, because errno is stored in thread-local storage
But Rust uses green thread, which means it's possible that multiple
tasks may run on a thread.
1. Task A calls function core::os::X. The system call fails and sets errno
2. Meanwhile (on the same thread) Task B is switched in and calls
core::os::Y. The system call fails and replaces the errno set from task A.
3. Task A is switched in again, and checks errno. It expects errno
returns the reason of failure of core::os::X, but what A sees is the
failure of core::os::Y
Is above case possible in Rust? If not, how does Rust prevents this?
Rust currently context switches in relatively few places, so it is
generally safe to make a system call then call errno - you won't get
descheduled between the two. Pipe sends and receives, as well as other
task-blocking concurrency types will cause you to be descheduled and
could cause errno to be invalidated.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
