https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=try 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-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-10T20:23:57+00:00 Alex Crichton alex@alexcrichton.com 2013-11-09T19:02:16+00:00 urn:sha1:e38a89d0b0fcc3b2f5cad600d7b3a16faeb94248 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 2013-11-04T23:48:34+00:00 Alex Crichton alex@alexcrichton.com 2013-11-04T23:45:46+00:00 urn:sha1:615444d26306ddaf62388c73ae1dc17e48b3b2e3 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. 2013-11-01T16:36:25+00:00 bors bors@rust-lang.org 2013-11-01T16:36:25+00:00 urn:sha1:7cff3c74b8d313154379ab73f18baab57c09bd33 This takes the last reforms on the `Option` type and applies them to `Result` too. For that, I reordered and grouped the functions in both modules, and also did some refactorings: - Added `as_ref` and `as_mut` adapters to `Result`. - Renamed `Result::map_move` to `Result::map` (same for `_err` variant), deleted other map functions. - Made the `.expect()` methods be generic over anything you can fail with. - Updated some doc comments to the line doc comment style - Cleaned up and extended standard trait implementations on `Option` and `Result` - Removed legacy implementations in the `option` and `result` module 2013-11-01T14:00:46+00:00 Marvin Löbel loebel.marvin@gmail.com 2013-10-31T22:09:24+00:00 urn:sha1:0d92c53f4a5707ee994d74d9e96995d7bac2ab13 Cleaned up the source in a few places Renamed `map_move` to `map`, removed other `map` methods Added `as_ref` and `as_mut` adapters to `Result` Added `fmt::Default` impl 2013-11-01T05:09:48+00:00 Alex Crichton alex@alexcrichton.com 2013-11-01T05:09:48+00:00 urn:sha1:8f258ab532eebce705b5eb27cc8635400992ca54 The previous method was unsound because you could very easily create two mutable pointers which alias the same location (not sound behavior). This hides the function which does so and then exports an explicit flush() function (with documentation about how it works). 2013-10-30T22:17:11+00:00 Alex Crichton alex@alexcrichton.com 2013-10-30T22:10:32+00:00 urn:sha1:452e5cdf11b30e17c69805a0bfc418feebb84081 Closes #9126 2013-10-25T17:31:57+00:00 Alex Crichton alex@alexcrichton.com 2013-10-25T00:30:36+00:00 urn:sha1:e8f72c38f4bf74e7291043917fdd0bae1404b407 Almost all languages provide some form of buffering of the stdout stream, and this commit adds this feature for rust. A handle to stdout is lazily initialized in the Task structure as a buffered owned Writer trait object. The buffer behavior depends on where stdout is directed to. Like C, this line-buffers the stream when the output goes to a terminal (flushes on newlines), and also like C this uses a fixed-size buffer when output is not directed at a terminal. We may decide the fixed-size buffering is overkill, but it certainly does reduce write syscall counts when piping output elsewhere. This is a *huge* benefit to any code using logging macros or the printing macros. Formatting emits calls to `write` very frequently, and to have each of them backed by a write syscall was very expensive. In a local benchmark of printing 10000 lines of "what" to stdout, I got the following timings: when | terminal | redirected ---------------------------------- before | 0.575s | 0.525s after | 0.197s | 0.013s C | 0.019s | 0.004s I can also confirm that we're buffering the output appropriately in both situtations. We're still far slower than C, but I believe much of that has to do with the "homing" that all tasks due, we're still performing an order of magnitude more write syscalls than C does.