TRPL: dining philosophers #25321
TRPL: dining philosophers #25321
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
oh, and i might not need the channel at the end: https://twitter.com/florob/status/597935275394912259 considering an extra 'cleanup' section |
| we are going to make some new threads, and that will return some handles to those | ||
| threads that let us control their operation. We need to explicitly annotate | ||
| the type here, though, due to an issue we’ll talk about later. The `_` is | ||
| a type placeholder. We’re saying “`handles` has is a vector of something, but |
steveklabnik
force-pushed
the
second_tutorial
branch
from
e6a6ce0 to
618ef96
Compare
|
I believe all nits are addressed. r? @alexcrichton |
|
So, maybe I'm just terribly dense, but I still don't see why you need the channel at all. AFAICT, it does not become obsolete by joining the threads, but is unnecessary from the get go. |
| fn done(&self) { | ||
| println!("{} is done eating.", self.name); | ||
|
|
||
| self.done.send(true).ok().expect("Couldn't finish eating"); |
There was a problem hiding this comment.
I'm still kinda worried about all these .ok().expect(...) calls throughout these examples, some of them I think may be giving the wrong impression. For example this doesn't really indicate anything about "couldn't finish eating" but rather that no one's listening for the notification that the eating is done. Down below there's:
.ok().expect("Couldn't aquire left mutex");If Err is returned, though, the mutex was indeed acquired, it was just poisoned.
Would it be possible to just use unwrap everywhere? I would consider unwrap as the idiomatic way to indicate that an error should not ever be happening here, and errors should definitely not ever be happening in these examples.
There was a problem hiding this comment.
I guess I've seen people mostly argue that unwrap gives a poor error message, and ok/expect at least lets you customize it.
that said, I'm sympathetic to the last thing you've said, so yeah, let me re-work it.
|
I do also agree with @Florob that the channel involvement here may not be pulling its weight by the time we get to the end. |
|
I added a thing at the end about removing the channel entirely. |
|
@Florob yeah, maybe that is true. sigh. |
steveklabnik
force-pushed
the
second_tutorial
branch
from
618ef96 to
cde1dd6
Compare
|
Okay, I removed the channels entirely, and use unwrap. |
| Now that we’ve got the basics in place, there’s a number of ways that we can | ||
| tackle the broader problem here. I like to start from the end first: let’s | ||
| set up a way for each philosopher to finish eating, and report back that | ||
| they’re done. As a tiny step, let’s make a method, and then loop through |
There was a problem hiding this comment.
"and report back that they're done", perhaps drop this phrase?
There was a problem hiding this comment.
nice catch. editing your own prose is so hard :(
| } | ||
| ``` | ||
|
|
||
| This `Table` has an array with five elements. These elements are all going |
There was a problem hiding this comment.
This may need to be rephrased as it's not just a plain vector instead of an array.
|
Looks good to me! A few last minor nits and otherwise r=me Nice chapter @steveklabnik! |
steveklabnik
force-pushed
the
second_tutorial
branch
from
cde1dd6 to
2ba6169
Compare
|
@bors: r=alexcrichton rollup |
|
📌 Commit 2ba6169 has been approved by |
…xcrichton This is a little rough, and it needs squashed and section headers, but i'd like to get some eyes on it sooner rather than later.
…xcrichton This is a little rough, and it needs squashed and section headers, but i'd like to get some eyes on it sooner rather than later.
| that the threads complete their work before the program exits. | ||
|
|
||
| If you run this program, you’ll see that the philosophers eat out of order! | ||
| We have mult-threading! |
There was a problem hiding this comment.
Blegh, I think this is already being tested in a rollup, but maybe there will be a quick chance to fix a couple things soon.
s/mult-threading/multi-threading/
Edit: Never mind, I was missing a paragraph. This is the only nit I found.
There was a problem hiding this comment.
I'll make a new PR for master, and work it into my backport. Thanks!
This is a little rough, and it needs squashed and section headers, but i'd like to get some eyes on it sooner rather than later.