This implements a fair amount of the unimpl() functionality in io::native
relating to filesystem operations. I've also modified all io::fs tests to run in
both a native and uv environment (so everything is actually tested).
There are a few bits of remaining functionality which I was unable to get
working:
* truncate on windows
* change_file_times on windows
* lstat on windows
I think that change_file_times may just need a better interface, but the other
two have large implementations in libuv which I didn't want to tackle trying to
copy. I found a `chsize` function to work for truncate on windows, but it
doesn't quite seem to be working out.
This implements a fair amount of the unimpl() functionality in io::native
relating to filesystem operations. I've also modified all io::fs tests to run in
both a native and uv environment (so everything is actually tested).
There are a two bits of remaining functionality which I was unable to get
working:
* change_file_times on windows
* lstat on windows
I think that change_file_times may just need a better interface, but lstat has a
large implementation in libuv which I didn't want to tackle trying to copy.
There are issues with reading stdin when it is actually attached to a pipe, but
I have run into no problems in writing to stdout/stderr when they are attached
to pipes.
Provide `Closed01` and `Open01` that generate directly from the
closed/open intervals from 0 to 1, in contrast to the plain impls for
f32 and f64 which generate the half-open [0,1).
Fixes#7755.
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 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#9105
There are issues with reading stdin when it is actually attached to a pipe, but
I have run into no problems in writing to stdout/stderr when they are attached
to pipes.
Provide `Closed01` and `Open01` that generate directly from the
closed/open intervals from 0 to 1, in contrast to the plain impls for
f32 and f64 which generate the half-open [0,1).
Fixes#7755.
These commits create a `Buffer` trait in the `io` module which represents an I/O reader which is internally buffered. This abstraction is used to reasonably implement `read_line` and `read_until` along with at least an ok implementation of `read_char` (although I certainly haven't benchmarked `read_char`).
This commit re-organizes the io::native module slightly in order to have a
working implementation of rtio::IoFactory which uses native implementations. The
goal is to seamlessly multiplex among libuv/native implementations wherever
necessary.
Right now most of the native I/O is unimplemented, but we have existing bindings
for file descriptors and processes which have been hooked up. What this means is
that you can now invoke println!() from libstd with no local task, no local
scheduler, and even without libuv.
There's still plenty of work to do on the native I/O factory, but this is the
first steps into making it an official portion of the standard library. I don't
expect anyone to reach into io::native directly, but rather only std::io
primitives will be used. Each std::io interface seamlessly falls back onto the
native I/O implementation if the local scheduler doesn't have a libuv one
(hurray trait ojects!)
This commit re-organizes the io::native module slightly in order to have a
working implementation of rtio::IoFactory which uses native implementations. The
goal is to seamlessly multiplex among libuv/native implementations wherever
necessary.
Right now most of the native I/O is unimplemented, but we have existing bindings
for file descriptors and processes which have been hooked up. What this means is
that you can now invoke println!() from libstd with no local task, no local
scheduler, and even without libuv.
There's still plenty of work to do on the native I/O factory, but this is the
first steps into making it an official portion of the standard library. I don't
expect anyone to reach into io::native directly, but rather only std::io
primitives will be used. Each std::io interface seamlessly falls back onto the
native I/O implementation if the local scheduler doesn't have a libuv one
(hurray trait ojects!)
I implemented BufWriter. I realize the use of conditions are on their way out for IO, but it does raise a condition if a write will not fit in the buffer for now.
I also replaced the seek code for MemWriter. It was adding the offset as a uint, which is unsound for negative offsets. It only happened to work because unsigned addition performs the same operation with two's complement, and sizeof(uint) <= sizeof(i64) so there was no (lack of) sign extension. I replaced this with computing an offset as an i64 and clamping to zero. I don't expect anyone will have use BufWriter with a byte buffer greater than 2^63 bytes any time soon.
@alexcrichton
Closes#10433
This trait is meant to abstract whether a reader is actually implemented with an
underlying buffer. For all readers which are implemented as such, we can
efficiently implement things like read_char, read_line, read_until, etc. There
are two required methods for managing the internal buffer, and otherwise
read_line and friends can all become default methods.
Closes#10334
Filled in the implementations of Writer and Seek for BufWriter. It
raises the io_error condition if a write cannot fit in the buffer.
The Seek implementation for MemWriter, which was incorrectly using
unsigned arithmatic to add signed offsets, has also been replaced.
This fills in some missing docs in the nums package. Let me know if this is on the right track for what's wanted for docs. I can probably fill in more in the future. Thanks.
(As a side note the precedence of the unary negative operator '-' tripped me up for a bit. Essentially I would expect `-25.0f32.sqrt()` to result in NaN instead of `-5.0`.)
I was benchmarking rust-http recently, and I saw that 50% of its time was spent
creating buffered readers/writers. Albeit rust-http wasn't using
std::rt::io::buffered, but the same idea applies here. It's much cheaper to
malloc a large region and not initialize it than to set it all to 0. Buffered
readers/writers never use uninitialized data, and their internal buffers are
encapsulated, so any usage of uninitialized slots are an implementation bug in
the readers/writers.
The commit messages have more details, but this removes all analysis and usage related to fixed_stack_segment and rust_stack attributes. It's now the assumption that we always have "enough stack" and we'll implement detection of stack overflow through other means.
The stack overflow detection is currently implemented for rust functions, but it is unimplemented for C functions (we still don't have guard pages).
I increased this to 4MB when I implemented abort-on-stack-overflow for Rust
functions. Now that the fixed_stack_segment attribute is removed, no rust
function will ever reasonably request 2MB of stack (due to calling an FFI
function).
The default size of 2MB should be plenty for everyday use-cases, and tasks can
still request more stack via the spawning API.
These two attributes are no longer useful now that Rust has decided to leave
segmented stacks behind. It is assumed that the rust task's stack is always
large enough to make an FFI call (due to the stack being very large).
There's always the case of stack overflow, however, to consider. This does not
change the behavior of stack overflow in Rust. This is still normally triggered
by the __morestack function and aborts the whole process.
C stack overflow will continue to corrupt the stack, however (as it did before
this commit as well). The future improvement of a guard page at the end of every
rust stack is still unimplemented and is intended to be the mechanism through
which we attempt to detect C stack overflow.
Closes#8822Closes#10155
I was benchmarking rust-http recently, and I saw that 50% of its time was spent
creating buffered readers/writers. Albeit rust-http wasn't using
std::rt::io::buffered, but the same idea applies here. It's much cheaper to
malloc a large region and not initialize it than to set it all to 0. Buffered
readers/writers never use uninitialized data, and their internal buffers are
encapsulated, so any usage of uninitialized slots are an implementation bug in
the readers/writers.
The logging macros all use libuv-based I/O, and there was one stray debug
statement in task::spawn which was executing before the I/O context was ready.
Remove it and add a test to make sure that we can continue to debug this sort of
code.
Closes#10405
The logging macros all use libuv-based I/O, and there was one stray debug
statement in task::spawn which was executing before the I/O context was ready.
Remove it and add a test to make sure that we can continue to debug this sort of
code.
Closes#10405
It appears that uv's support for interacting with a stdio stream as a tty when
it's actually a pipe is pretty problematic. To get around this, promote a check
to see if the stream is a tty to the top of the tty constructor, and bail out
quickly if it's not identified as a tty.
Closes#10237
It turns out that the uv implementation would cause use-after-free if the idle
callback was used after the call to `close`, and additionally nothing would ever
really work that well if `start()` were called twice. To change this, the
`start` and `close` methods were removed in favor of specifying the callback at
creation, and allowing destruction to take care of closing the watcher.
Fully support multiple lifetime parameters on types and elsewhere, removing special treatment for `'self`. I am submitting this a touch early in that I plan to push a new commit with more tests specifically targeting types with multiple lifetime parameters -- but the current code bootstraps and passes `make check`.
Fixes#4846
This Fixes#10265 and paves the way for fixing #9543. It works by adding a 'package_id' attribute by default for library crates that don't specify it. This is necessary to use the 'extern mod foo = "bar"' form instead of 'extern mod foo(name="bar") (as per #9543), because the former adds a required package_id when trying to link with the bar crate. I added a simple test to ensure that the default package_id value is being generated, and also added an explicit package_id in the link attribute in all rust libs to avoid getting warnings about default package_id values when building rust.
I'm not sure this is something you're interested in, but I was playing around the Any trait a bit and I wanted to try it as a key in a HashMap. To do that, TypeId needs to implement IterBytes.
This renames to_str_ascii to as_str_ascii and makes it non-copying,
which is possible now that strings no longer have a hidden extra
byte/null terminator.
Fixes#6120.
This renames to_str_ascii to as_str_ascii and makes it non-copying,
which is possible now that strings no longer have a hidden extra
byte/null terminator.
Fixes#6120.
There were a few ambiguous error messages which look like they could have
cropped up from either the rust compiler for the format string parser. To
differentiate, the prefix 'invalid format string' is now added in front of all
format string errors.
cc #9970
There were a few ambiguous error messages which look like they could have
cropped up from either the rust compiler for the format string parser. To
differentiate, the prefix 'invalid format string' is now added in front of all
format string errors.
cc #9970
This binds to the appropriate pthreads_* and Windows specific functions
and calls them from Rust. This allows for removal of the C++ support
code for threads.
Fixes#10162
Right now if you're running a program with its output piped to some location and
the program decides to go awry, when you kill the program via some signal none
of the program's last 4K of output will get printed to the screen. In theory the
solution to this would be to register a signal handler as part of the runtime
which then flushes the output stream.
I believe that the current behavior is far enough from what's expected that we
shouldn't be providing this sort of "super buffering" by default when stdout
isn't attached to a tty.
This isn't quite as fancy as the struct in #9913, but I'm not sure we should be exposing crate names/hashes of the types. That being said, it'd be pretty easy to extend this (the deterministic hashing regardless of what crate you're in was the hard part).
Right now if you're running a program with its output piped to some location and
the program decides to go awry, when you kill the program via some signal none
of the program's last 4K of output will get printed to the screen. In theory the
solution to this would be to register a signal handler as part of the runtime
which then flushes the output stream.
I believe that the current behavior is far enough from what's expected that we
shouldn't be providing this sort of "super buffering" by default when stdout
isn't attached to a tty.
This fleshes out the io::file module a fair bit more, adding all of the functionality that I can think of that we would want. Some questions about the representation which I'm curious about:
* I modified `FileStat` to be a little less platform-agnostic, but it's still fairly platform-specific. I don't want to hide information that we have, but I don't want to depend on this information being available. One possible route is to have an `extra` field which has all this os-dependent stuff which is clearly documented as it should be avoided.
* Does it make sense for directory functions to be top-level functions instead of static methods? It seems silly to import `std::rt::io::file` and `std::rt::io::File` at the top of files that need to deal with directories and files.
