https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=try 2014-04-04T16:31:21+00:00 2014-04-04T16:31:21+00:00 Corey Richardson corey@octayn.net 2014-02-24T18:16:03+00:00 urn:sha1:308c03501a9a49d058f2ad76dd17a4e593ce7be7 These wrappers are bound to a specific libc, and they don't need to be part of libstd. 2014-03-31T22:17:12+00:00 Alex Crichton alex@alexcrichton.com 2014-03-27T22:09:47+00:00 urn:sha1:9a3d04ae7629f6f273643b3a14f106726842be6a 2014-03-29T00:12:21+00:00 Brian Anderson banderson@mozilla.com 2014-03-22T01:05:05+00:00 urn:sha1:451e8c1c6178750a4c1789f40749562164a980b7 Closes #2569 2014-03-28T19:46:44+00:00 bors bors@rust-lang.org 2014-03-28T19:46:44+00:00 urn:sha1:42e1003e4a2dd4d3a7e800c2f5b99bf77a4b635e Some unix platforms will send a SIGPIPE signal instead of returning EPIPE from a syscall by default. The native runtime doesn't install a SIGPIPE handler, causing the program to die immediately in this case. This brings the behavior in line with libgreen by ignoring SIGPIPE and propagating EPIPE upwards to the application in the form of an IoError. Closes #13123 2014-03-28T18:21:48+00:00 Alex Crichton alex@alexcrichton.com 2014-03-26T21:34:52+00:00 urn:sha1:68c2706780031e3aac6cccea0f7b867ad5eff13a Some unix platforms will send a SIGPIPE signal instead of returning EPIPE from a syscall by default. The native runtime doesn't install a SIGPIPE handler, causing the program to die immediately in this case. This brings the behavior in line with libgreen by ignoring SIGPIPE and propagating EPIPE upwards to the application in the form of an IoError. Closes #13123 2014-03-28T18:07:58+00:00 Alex Crichton alex@alexcrichton.com 2014-03-25T15:44:40+00:00 urn:sha1:0e190b9a4ad92645e8f63c72c66cc89a596f1971 It turns out that on linux, and possibly other platforms, child processes will continue to accept signals until they have been *reaped*. This means that once the child has exited, it will succeed to receive signals until waitpid() has been invoked on it. This is unfortunate behavior, and differs from what is seen on OSX and windows. This commit changes the behavior of Process::signal() to be the same across platforms, and updates the documentation of Process::kill() to note that when signaling a foreign process it may accept signals until reaped. Implementation-wise, this invokes waitpid() with WNOHANG before each signal to the child to ensure that if the child has exited that we will reap it. Other possibilities include installing a SIGCHLD signal handler, but at this time I believe that that's too complicated. Closes #13124 2014-03-18T20:51:29+00:00 Alex Crichton alex@alexcrichton.com 2014-03-16T08:08:56+00:00 urn:sha1:848f7b734ec88964879f5a3051b940d48469ce2e A major discoverability issue with rustdoc is that all crates have their documentation built in isolation, so it's difficult when looking at the documentation for libstd to learn that there's a libcollections crate with a HashMap in it. This commit moves rustdoc a little closer to improving the multiple crate experience. This unifies all search indexes for all crates into one file so all pages share the same search index. This allows searching to work across crates in the same documentation directory (as the standard distribution is currently built). This strategy involves updating a shared file amongst many rustdoc processes, so I implemented a simple file locking API for handling synchronization for updates to the shared files. cc #12554 2014-03-14T22:16:31+00:00 bors bors@rust-lang.org 2014-03-14T22:16:31+00:00 urn:sha1:26fdfa124c065872a0b3c98e7234b05b00840f20 I ignored AtomicU64 methods on MIPS target because libgcc doesn't implement MIPS32 64-bit atomic operations. Otherwise it would cause link failure. By the way, the patched LLVM doesn't have MIPS split stack anymore. Should I file an issue about that? 2014-03-14T04:06:34+00:00 bors bors@rust-lang.org 2014-03-14T04:06:34+00:00 urn:sha1:4443fb3cfa945cf7cb791cf8f2ec81b7faf25132 This is something that is plausibly useful, and is provided by libuv. This is not currently surfaced as part of the `TcpStream` type, but it may possibly appear in the future. For now only the raw functionality is provided through the Rtio objects. 2014-03-14T03:13:36+00:00 Jyun-Yan You jyyou@cs.nctu.edu.tw 2014-03-13T06:35:24+00:00 urn:sha1:6d7e86d099cf33821398731f750b36df564ca5d2 I ignored AtomicU64 methods on MIPS target because libgcc doesn't implement MIPS32 64-bit atomic operations. Otherwise it would cause link failure.