| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
I still plan on reorganizing the internals of the IO module a bit, but this is the major move which has been on the horizon for awhile.
|
|
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.
|
|
|
|
|
|
|
|
for getting process termination status, or the signal that terminated a process.
A test has been added to rtio-processes.rs to ensure signal termination is picked up correctly.
|
|
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 #8822
Closes #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.
|
|
Fixes #10271
|
|
Turns out the pipe names must have special names on windows. Once we have
special names, all the tests pass just fine.
Closes #10386
|
|
To enable test on android bot #9120
some tests are disabled and can be fixed further.
|
|
|
|
Closes #8606
|
|
Fixes #10271
|
|
|
|
Mostly just using the `system` abi where possible.
|
|
Turns out the pipe names must have special names on windows. Once we have
special names, all the tests pass just fine.
Closes #10386
|
|
|
|
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.
|
|
This exposes the ability to change the modification and access times on a file.
Closes #10266
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
help of apk
|
|
nikomatsakis/rust/issue-4846-multiple-lifetime-parameters-7, r=pnkfelix
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.
|
|
|
|
|
|
|
|
Closes #10240
|
|
|
|
|
|
|
