More scheduler and I/O work #5409
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| // XXX: Can't put doc comments on macros | ||
| // Raised by `Stream` instances on error. Returning `true` from the handler | ||
| // indicates that the `Stream` should continue, `false` that it should fail. | ||
| condition! { |
There was a problem hiding this comment.
A note here, as I've seen a few conditions getting written this way lately: there's seldom a need to have a return value from a condition that tells the raise-site that it should fail; the handler itself can just fail (and indeed, untrapped conditions already fail). There's just as much context (more actually) visible to a backtrace if you let the handler / absence-of-handler itself fail.
Generally the only things that should show up in the return slot of a condition are data to use for recovery-and-continuation: sentinel values or replacement values, things that represent the handler saying "oh, well, use this value instead". If no such data is required or plausible (i.e. if the only reasonable thing one might do to recover is "ignore the error") then just put () in the return slot. If control proceeds past the condition.raise() line, you know a caller trapped the error and wants you to ignore it and continue.
There was a problem hiding this comment.
I see. I'll make this not return a bool.
I intend to do some big refactoring and don't want to deal w/ std just now
The bots were showing a segfault that I can't reproduce. Assuming it's varargs related so let's not use printf
No more mapping uv structs to Rust structs
This is an internal interface. I want to use rt::io for public interfaces.
Can make turnaround of testing changes to core/std/syntax much faster.
I can already see these are going to get massive. Putting them into multiple files.
TESTARGS=--newrt make check-stage1-rpass Conflicts: src/rt/rustrt.def.in
I don't want any global one-time initalization functions because that will make embedding harder.
Conflicts: src/libcore/rt/context.rs src/libcore/rt/sched.rs src/libcore/rt/thread.rs src/libcore/rt/uv.rs
bors
added a commit
that referenced
this pull request
Mar 25, 2013
r? There are a lot of commits here, but not all that much substance. Mostly just refactoring. I started sketching out the beginnings of a very simple I/O API in `core::rt::io` that represents I/O streams as a single `Stream` trait instead of `Reader` / `Writer` pairs. This seems to be the more common pattern (at least this is how the .NET BCL does it) and it seems to me that separate readers and writers would make duplex streams very awkward. Regardless, I don't intend to go very far down the I/O API design road without some mailing list discussion. I've also started on the uv bindings for file I/O but haven't gotten very far. Also hooked up the new scheduler to `rust_start` and the compiletest driver. 70% of run-pass test cases already pass, but I wouldn't read too much into that. I also split the direct, low-level uv bindings in two so that the scheduler can have its own set, leaving `std::net` on its own.
oli-obk
pushed a commit
to oli-obk/rust
that referenced
this pull request
May 2, 2020
Downgrade let_unit_value to pedantic Given that the false positive in rust-lang#1502 is marked E-hard and I don't have much hope of it getting fixed, I think it would be wise to disable this lint by default. I have had to suppress this lint in every substantial codebase (\>100k line) I have worked in. Any time this lint is being triggered, it's always the false positive case. The motivation for this lint is documented as: > A unit value cannot usefully be used anywhere. So binding one is kind of pointless. with this example: > ```rust > let x = { > 1; > }; > ``` Sure, but the author would find this out via an unused_variable warning or from `x` not being the type that they need further down. If there ends up being a type error on `x`, clippy's advice isn't going to help get the code compiling because it can only run if the code already compiles. changelog: Remove let_unit_value from default set of enabled lints
oli-obk
pushed a commit
to oli-obk/rust
that referenced
this pull request
May 2, 2020
Rollup of 11 pull requests Successful merges: - rust-lang#5406 (Fix update_lints) - rust-lang#5409 (Downgrade let_unit_value to pedantic) - rust-lang#5410 (Downgrade trivially_copy_pass_by_ref to pedantic) - rust-lang#5412 (Downgrade inefficient_to_string to pedantic) - rust-lang#5415 (Add new lint for `Result<T, E>.map_or(None, Some(T))`) - rust-lang#5417 (Update doc links and mentioned names in docs) - rust-lang#5419 (Downgrade unreadable_literal to pedantic) - rust-lang#5420 (Downgrade new_ret_no_self to pedantic) - rust-lang#5422 (CONTRIBUTING.md: fix broken triage link) - rust-lang#5424 (Incorrect suspicious_op_assign_impl) - rust-lang#5425 (Ehance opt_as_ref_deref lint.) Failed merges: - rust-lang#5345 (Add lint for float in array comparison) - rust-lang#5411 (Downgrade implicit_hasher to pedantic) - rust-lang#5428 (Move cognitive_complexity to nursery) r? @ghost changelog: rollup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
r?
There are a lot of commits here, but not all that much substance. Mostly just refactoring.
I started sketching out the beginnings of a very simple I/O API in
core::rt::iothat represents I/O streams as a singleStreamtrait instead ofReader/Writerpairs. This seems to be the more common pattern (at least this is how the .NET BCL does it) and it seems to me that separate readers and writers would make duplex streams very awkward. Regardless, I don't intend to go very far down the I/O API design road without some mailing list discussion.I've also started on the uv bindings for file I/O but haven't gotten very far.
Also hooked up the new scheduler to
rust_startand the compiletest driver. 70% of run-pass test cases already pass, but I wouldn't read too much into that.I also split the direct, low-level uv bindings in two so that the scheduler can have its own set, leaving
std::neton its own.