Remove all thread-blocking functions in std::os
#10057
Comments
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Oct 29, 2013
This commit moves all thread-blocking I/O functions from the std::os module. Their replacements can be found in either std::rt::io::file or in a hidden "old_os" module inside of native::file. I didn't want to outright delete these functions because they have a lot of special casing learned over time for each OS/platform, and I imagine that these will someday get integrated into a blocking implementation of IoFactory. For now, they're moved to a private module to prevent bitrot and still have tests to ensure that they work. The api of the io::file modules has also been reworked in this commit. The open_reader and open_writer functions have had open and create counterparts created, neither of which take any arguments (allowing for easy usage). The top-level 'file::open' function was renamed to 'file::open_stream', and top-level 'file::create' and 'file::open' functions were added (same as the methods). I also removed the traits that add functionality to the platform's Path structure. It was unfortunate having to import all of these traits, and it was unclear whether they would ever be implemented for anything other than Path. For this reason, they're now just an extra impl block on Path itself. I've also expanded the extensions to a few more methods defined on Path, most of which were previously defined in std::os but now have non-thread-blocking implementations as part of using the current IoFactory. Closes rust-lang#10057
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
All functions which block the current thread need to get deleted. This includes almost all of the
std::osmodule. This is all legacy code at this point and it needs to get all rebuilt on the new runtime's libuv implementation.Most file operations are exposed through
rt::io::file, which I think is comprehensive enough, but this may involve adding more uv bindings where necessary.I'm not tagging this as E-easy because I don't think that it's a straightforward refactoring. This will involve understanding how to migrate functions and being sure to expose errors which occur at the underlying layer.
This may also be best held off until #6163 is dealt with, but it's going to be painful in either way from what I can tell.
Nominating for 1.0, we can never block a thread in a syscall.
The text was updated successfully, but these errors were encountered: