On Thu, Nov 14, 2013 at 7:53 PM, Patrick Walton <[email protected]> wrote: > On 11/15/13 9:51 AM, Daniel Micay wrote: >> >> The same is true for 1:1 vs. M:N threading. If a task doesn't map 1:1 >> to a thread ID and thread-local data, support for C libraries using >> thread-local data will always be stuck with an inferior API to C/C++. > > > Unless you pin the task, no?
If you pin the task and other tasks aren't allowed to use the thread, it would work. The library would have to do this in all the entry points to provide safety and there would have to be no way of unpinning a task in safe code or at least a separate mandatory pinning concept. >> There's also the inability to directly use static thread-local data >> which is very fast and easy to use. > > I think we could just implement static task-local data using some sort of > life-before-main under the hood. The issue is that the thread-local data is used by outputting accesses through an x86 segment register (and similarly on other architectures) so 1:1 vs. M:N would become a compile-time choice. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
