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
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
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
So far, we've used the term POD "Plain Old Data" to refer to types that
can be safely copied. However, this term is not consistent with the
other built-in bounds that use verbs instead. This patch renames the `Pod`
kind into `Copy`.
RFC: 0003-opt-in-builtin-traits
r? @nikomatsakis
HashMap and HashSet require keys to implement TotalEq. This makes it possible to use TypeId as a HashMap key again.
Question for reviewers: assuming we want to support `HashMap<TypeId, whatever>`, would it make sense to add a relevant test? If so, should it go to libcollections or libstd?
Summary:
So far, we've used the term POD "Plain Old Data" to refer to types that
can be safely copied. However, this term is not consistent with the
other built-in bounds that use verbs instead. This patch renames the Pod
kind into Copy.
RFC: 0003-opt-in-builtin-traits
Test Plan: make check
Reviewers: cmr
Differential Revision: http://phabricator.octayn.net/D3
Apparently we had forgotten to do this for freebsd, causing possible problems
on FreeBSD 10. The discussion in #12324 has some more details about how it's
missing.
# Summary
Changed `iter::Extendable` and `iter::FromIterator` to take a `Iterator` by value.
These functions always exhaust the passed `Iterator`, and are often used for transferring the values of a new `Iterator` directly into a data structure, so using them usually require the use of the `&mut` operator:
```
foo.extend(&mut bar.move_iter()); // Transfer content from bar into foo
let mut iter = ...;
foo.extend(&mut iter); // iter is now empty
```
This patch changes both the `FromIterator` and `Extendable` traits to take the iterator by value instead, which makes the common case of using these traits less heavy:
```
foo.extend(bar.move_iter()); // Transfer content from bar into foo
let iter = ...;
foo.extend(iter);
// iter is now inaccessible if it moved
// or unchanged if it was Pod and copied.
```
# Composability
This technically makes the traits less flexible from a type system pov, because they now require ownership.
However, because `Iterator` provides the `ByRef` adapter, there is no loss of functionality:
```
foo.extend(iter.by_ref()); // Same semantic as today, for the few situations where you need it.
```
# Motivation
This change makes it less painful to use iterators for shuffling values around between collections, which makes it more acceptable to always use them for this, enabling more flexibility.
For example, `foo.extend(bar.move_iter())` can generally be the fastest way to append an collections content to another one, without both needing to have the same type. Making this easy to use would allow the removal of special cased methods like `push_all()` on vectors. (See https://github.com/mozilla/rust/issues/12456)
I opened https://github.com/mozilla/rust/issues/13038 as well, to discuss this change in general if people object to it.
# Further work
This didn't change the `collect()` method to take by value `self`, nor any of the other adapters that also exhaust their iterator argument. For consistency this should probably happen in the long term, but for now this is too much trouble, as every use of them would need to be checked for accidentally changed semantic by going `&mut self -> self`. (which allows for the possibility that a `Pod` iterator got copied instead of exhausted without generating a type error by the change)
Apparently we had forgotten to do this for freebsd, causing possible problems
on FreeBSD 10. The discussion in #12324 has some more details about how it's
missing.
This commit contains an implementation of synchronous, bounded channels for
Rust. This is an implementation of the proposal made last January [1]. These
channels are built on mutexes, and currently focus on a working implementation
rather than speed. Receivers for sync channels have select() implemented for
them, but there is currently no implementation of select() for sync senders.
Rust will continue to provide both synchronous and asynchronous channels as part
of the standard distribution, there is no intent to remove asynchronous
channels. This flavor of channels is meant to provide an alternative to
asynchronous channels because like green tasks, asynchronous channels are not
appropriate for all situations.
[1] - https://mail.mozilla.org/pipermail/rust-dev/2014-January/007924.html
* Remove clone-ability from all primitives. All shared state will now come
from the usage of the primitives being shared, not the primitives being
inherently shareable. This allows for fewer allocations for stack-allocated
primitives.
* Add `Mutex<T>` and `RWLock<T>` which are stack-allocated primitives for purely
wrapping a piece of data
* Remove `RWArc<T>` in favor of `Arc<RWLock<T>>`
* Remove `MutexArc<T>` in favor of `Arc<Mutex<T>>`
* Shuffle around where things are located
* The `arc` module now only contains `Arc`
* A new `lock` module contains `Mutex`, `RWLock`, and `Barrier`
* A new `raw` module contains the primitive implementations of `Semaphore`,
`Mutex`, and `RWLock`
* The Deref/DerefMut trait was implemented where appropriate
* `CowArc` was removed, the functionality is now part of `Arc` and is tagged
with `#[experimental]`.
* The crate now has #[deny(missing_doc)]
* `Arc` now supports weak pointers
This is not a large-scale rewrite of the functionality contained within the
`sync` crate, but rather a shuffling of who does what an a thinner hierarchy of
ownership to allow for better composability.
This is the final nail in the coffin for the crate map. The `start` function for
libgreen now has a new added parameter which is the event loop factory instead
of inferring it from the crate map. The two current valid values for this
parameter are `green::basic::event_loop` and `rustuv::event_loop`.
The proper usage of shared types is now sharing through `&self` rather than
`&mut self` because the mutable version will provide stronger guarantees (no
aliasing on *any* thread).
std: remove the `equals` method from `TotalEq`.
`TotalEq` is now just an assertion about the `Eq` impl of a
type (i.e. `==` is a total equality if a type implements `TotalEq`) so
the extra method is just confusing.
Also, a new method magically appeared as a hack to allow deriving to
assert that the contents of a struct/enum are also TotalEq, because the
deriving infrastructure makes it very hard to do anything but create a
trait method. (You didn't hear about this horrible work-around from me
:(.)
`TotalEq` is now just an assertion about the `Eq` impl of a
type (i.e. `==` is a total equality if a type implements `TotalEq`) so
the extra method is just confusing.
Also, a new method magically appeared as a hack to allow deriving to
assert that the contents of a struct/enum are also TotalEq, because the
deriving infrastructure makes it very hard to do anything but create a
trait method. (You didn't hear about this horrible work-around from me
:(.)
`Vec` is now used for the internal buffer instead of `~[]`. Some module
level documentation somehow ended up attached to `BufferedReader` so I
fixed that as well.
This needs to be removed as part of removing `~[T]`. Partial type hints
are now allowed, and will remove the need to add a version of this
method for `Vec<T>`. For now, this involves a few workarounds for
partial type hints not completely working.
`Vec` is now used for the internal buffer instead of `~[]`. Some module
level documentation somehow ended up attached to `BufferedReader` so I
fixed that as well.
This commit removes the `get()` method from `Ref` and `RefMut` in favor of the `*` operator, and removes all usage of the `deref()` function manually from rustc, favoring using `*` instead.
Some of the code is a little wacky, but that's due to either #13044 or #13042
I've found a common use case being to fill a slice (not an owned vector)
completely with bytes. It's posible for short reads to happen, and if you're
trying to get an exact number of bytes then this helper will be useful.
`FormatMessageW()` is called by `std::os::last_os_error()` to convert
errno into string, but the function may fail on non-english locale.
I don't know why it fails, but anyway it's better to return errno
than to `fail!()` in the case.
Fixes#13075Fixes#13073
