https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=master 2013-11-12T04:44:07+00:00 2013-11-12T04:44:07+00:00 Alex Crichton alex@alexcrichton.com 2013-11-11T06:46:32+00:00 urn:sha1:49ee49296b65f3d807142f3326bee71dd7e13290 2013-11-12T03:31:14+00:00 bors bors@rust-lang.org 2013-11-12T03:31:14+00:00 urn:sha1:8b4683d79d4b74f53808470cd2f98b23a0af9b93 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. 2013-11-12T01:37:14+00:00 Matthew Iselin matthew@theiselins.net 2013-11-12T01:37:14+00:00 urn:sha1:f698decf3701cc51a61bbc3e36971898339ba91e A test has been added to rtio-processes.rs to ensure signal termination is picked up correctly. 2013-11-11T18:40:34+00:00 Alex Crichton alex@alexcrichton.com 2013-11-06T23:16:04+00:00 urn:sha1:7755ffd0131fa99ca5d58bdd5eab443b44d5a1ff 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 2013-11-11T18:08:03+00:00 Alex Crichton alex@alexcrichton.com 2013-11-11T18:08:03+00:00 urn:sha1:cdf7d63bfce33d2390e3a0a27e01a07f262834e7 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. 2013-11-11T14:21:16+00:00 bors bors@rust-lang.org 2013-11-11T14:21:16+00:00 urn:sha1:c47986b6751400ef30fa165d0278ec3fa212d54d To enable test on android bot #9120 some tests are disabled and can be fixed further. 2013-11-11T10:00:48+00:00 Corey Richardson corey@octayn.net 2013-11-11T10:00:48+00:00 urn:sha1:2c18983ea59e44762cb4d9f4cb95733009ce2002 2013-11-10T20:23:57+00:00 Alex Crichton alex@alexcrichton.com 2013-11-09T19:02:16+00:00 urn:sha1:e38a89d0b0fcc3b2f5cad600d7b3a16faeb94248 2013-11-10T09:37:12+00:00 Alex Crichton alex@alexcrichton.com 2013-11-08T04:13:25+00:00 urn:sha1:86a321b65dcc5253f61202b2fdaac41f275344ce 2013-11-10T09:37:11+00:00 Alex Crichton alex@alexcrichton.com 2013-11-07T23:24:30+00:00 urn:sha1:b652bbc6700e36c9ad80105c89d7fc2e3afec111 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