Implement a native mutex type #10479
Conversation
|
@alexcrichton On Windows Vista+, SRW locks allow static initialization, are pointer-sized and faster than critical sections (http://alax.info/blog/1185), and the only possible downside they appear to have is that they are non-recursive. If Windows XP support is desired, the pointer sized storage for the SRW lock can instead be used for a compare-and-swapped pointer to a critical section when the OS version is < Vista. |
|
Interesting! I'm not sure if we're officially supporting XP or not, but sadly our If this does end up getting landed though, I'll definitely open an issue with that link because it would be pretty awesome to not leak allocations or have to worry about them at all. |
|
I've also added a commit which moves all |
|
@alexcrichton: it would be really need to replace the libstdc++/libc++ dependency with a libc++abi dependency, which we could ship ourselves (300KiB) |
|
It appears that we may be able to use llvm's libcxxabi project along with libunwind. These can both be statically linked to librustrt, thereby lifting our dynamic dependence on libstdc++. I'm not 100% certain that it would work, but regardless it's probably a better issue for another time. |
|
r=me with typo fix |
|
I think we'll probably want a separate mutex and condition variable like C++11. Windows has native support for them now and they can be emulated on older versions. http://en.cppreference.com/w/cpp/thread/condition_variable |
This mutex is built on top of pthreads for unix and the related windows apis on windows. This is a straight port of the lock_and_signal type from C++ to rust. Almost all operations on the type are unsafe, and it's definitely not recommended for general use. Closes rust-lang#9105
A the same time this purges all runtime support needed for statically initialized mutexes, moving all users over to the new Mutex type instead.
Explicitly have the only C++ portion of the runtime be one file with exception handling. All other runtime files must now live in C and be fully defined in C.
This adds a new `std::unstable::mutex` module which contains bindings to the platform-provided mutexes. This module is pretty much entirely unsafe to use, but is critical for the runtime and dropping our C++ dependency. The actual implementation is to do a compare-and-swap on an initially uninitialized pointer. Pthreads does allow for static initialization, so this wouldn't be necessary if we had all the proper headers and whatnot, but windows it looks like will always require some sort of compare-and-swap operation. For now, I didn't want to have to define all the pthreads headers, so I continue to just malloc the pthreads lock/cvar. After this, there's only one remaining C++ component of rust, and that's unwinding.
In this series of commits, I've implemented static linking for rust. The scheme I implemented was the same as my [mailing list post](https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html). The commits have more details to the nitty gritty of what went on. I've rebased this on top of my native mutex pull request (#10479), but I imagine that it will land before this lands, I just wanted to pre-emptively get all the rebase conflicts out of the way (becuase this is reorganizing building librustrt as well). Some contentious points I want to make sure are all good: * I've added more "compiler chooses a default" behavior than I would like, I want to make sure that this is all very clearly outlined in the code, and if not I would like to remove behavior or make it clearer. * I want to make sure that the new "fancy suite" tests are ok (using make/python instead of another rust crate) If we do indeed pursue this, I would be more than willing to write up a document describing how linking in rust works. I believe that this behavior should be very understandable, and the compiler should never hinder someone just because linking is a little fuzzy.
Don't lint `manual_clamp` in const contexts. fixes rust-lang#10474 Probably worth including in the sync. r? `@flip1995` changelog: [`manual_clamp`]: Don't lint in const contexts.
This adds a new
std::unstable::mutexmodule which contains bindings to the platform-provided mutexes. This module is pretty much entirely unsafe to use, but is critical for the runtime and dropping our C++ dependency.The actual implementation is to do a compare-and-swap on an initially uninitialized pointer. Pthreads does allow for static initialization, so this wouldn't be necessary if we had all the proper headers and whatnot, but windows it looks like will always require some sort of compare-and-swap operation. For now, I didn't want to have to define all the pthreads headers, so I continue to just malloc the pthreads lock/cvar.
After this, there's only one remaining C++ component of rust, and that's unwinding.