Unclear when you need to be in a rust thread

[mvdnes]

Description

I am currently trying to interface with a C library (SDL) which runs on its own thread and need a callback.

First I wanted to use an Arc<RWLock<DList<T>>> for this purpose. When confronted with runtime failures, someone on the IRC pointed out to me that an RWLock can only be used from within a Rust thread.

This makes a lot of sense, but was not clear at all from the docs. Maybe it could be pointed out what functions / structures can not be used from a bare pthread?

(Also, is there a Lock which can be used both from a phtread and from a rust thread?)

[alexcrichton]

The library have the notion of a runtime which is provided by all rust tasks. Any service provided by the runtime will require a local task be available. Some examples are:

• Descheduling/rescheduling (channels, sync::lock, etc)
• task-local-data
• I/O
• task spawning

The public primitives in sync are all built on task descheduling/rescheduling to work properly across multiple scheduling models, hence requiring a local task to be available.

You may be interested in std::rt::mutex which are bindings to the native lock, be it pthreads or the windows equivalent.

This definition and line of "what it means to be a task" is constantly evolving over time, so I'm going to close this for now as not particularly actionable. This is somewhat decently covered by http://doc.rust-lang.org/std/rt/ and http://doc.rust-lang.org/guide-runtime.html today, but specific improvements would always be welcome!