Skip to content

Roll-up PRs in the queue #18978

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 38 commits into from Nov 16, 2014
Merged

Roll-up PRs in the queue #18978

merged 38 commits into from Nov 16, 2014

Conversation

ghost
Copy link

@ghost ghost commented Nov 15, 2014

No description provided.

IanConnolly and others added 12 commits November 13, 2014 19:52
The previous implementation was very likely to cause panics during
unwinding through this process:

- child panics, drops its receiver
- taskpool comes back around and sends another job over to that child
- the child receiver has hung up, so the taskpool panics on send
- during unwinding, the taskpool attempts to send a quit message to
  the child, causing a panic during unwinding
- panic during unwinding causes a process abort

This meant that TaskPool upgraded any child panic to a full process
abort. This came up in Iron when it caused crashes in long-running
servers.

This implementation uses a single channel to communicate between
spawned tasks and the TaskPool, which significantly reduces the complexity
of the implementation and cuts down on allocation. The TaskPool uses
the channel as a single-producer-multiple-consumer queue.

Additionally, through the use of send_opt and recv_opt instead of
send and recv, this TaskPool is robust on the face of child panics,
both before, during, and after the TaskPool itself is dropped.

Due to the TaskPool no longer using an `init_fn_factory`, this is a

[breaking-change]

otherwise, the API has not changed.

If you used `init_fn_factory` in your code, and this change breaks for
you, you can instead use an `AtomicUint` counter and a channel to
move information into child tasks.
The examples in the documentation for syntax::ext::deriving::encodable
are outdated, and do not work. To fix this, the following changes are
applied:

- emit_field() -> emit_struct_field()
- read_field() -> read_struct_field()
- Use Result to report errors
- Add the mut keyword to Encoder/Decoder
- Prefer Encodable::encode() to emit_uint
It is necessary to have #[deriving(Default)] for struct containing
cells like Cell<u32>.
Hide the search form and expand/collapse buttons, since they aren't useful when printed.
A recent change turned off inheritance for the #[stable] by default, but
failed to catch all the cases where this was being used in std. This
patch fixes that problem.
This commit slightly tweaks the counting of impl blocks and structs for
the stability summary (so that the block itself isn't counted for
inherent impls, and the fields aren't counted for structs).
@rust-highfive
Copy link
Contributor

warning Warning warning

  • These commits modify unsafe code. Please review it carefully!

bors added a commit that referenced this pull request Nov 15, 2014
This test was somewhat sketchy already with a `loop` around `write`, so this
just adds some explicit synchronization to only call `write` once and guarantee
that the error happens.

Closes #18900
@alexcrichton
Copy link
Member

🌴 thanks @jakub-!

@brson
Copy link
Contributor

brson commented Nov 15, 2014

Thanks @jakub-

bors added a commit that referenced this pull request Nov 16, 2014
bors added a commit that referenced this pull request Nov 16, 2014
@bors bors closed this Nov 16, 2014
@bors bors merged commit 892d4e2 into rust-lang:master Nov 16, 2014
@ghost ghost deleted the roll-up branch November 16, 2014 18:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.