-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Technical nits: Threads and Drop #63
Comments
I don't think this is true. AFAIK, it only blocks upon leaving the |
Hi @QuineDot, Thanks for reading the slides so carefully :-)
Okay, I had not thought of it from that perspective. But let me first understand if we understand the same by daemon thread? I first encountered the term in Python where a daemon thread is a thread which will not keep the program alive. That is all — non-daemon threads will keep the program alive, even if you exit from the main thread. When teaching the class, I was told that Java people also know the term with the same meaning. With that definition of daemon thread, I believe that dropping the Now, you're right that the main thread cannot exit before the spawned thread if it calls
Right, I see that there are differences in when you get panics. However, is the ability to borrow local variables not the important difference? Remember that this is taught to people in a classroom on Day 4 — they'll have seen ~15 hours of Rust code at this point, so I need to focus on the most important points 😄 (while also not writing untrue things, of course). I'm working on support for speaker notes #53 and with those, there will be a place to fill in details which the slides cannot contain. When I give the course, we do speak a lot about panics and I normally live-code some panics to show people how they can catch them (if unwinding is enabled). |
Ah, okay -- that isn't the meaning I inferred, so I guess I didn't know that phrase. Also I take your point about being Day 4 (although you're the one who brought up panics 😉). Talking about things in terms of However, I do still think there's probable confusion here, based on the slides alone anyway. When writing my first stab at a reply, I realized where most my "this is confusing and going to be frustrating" gripes come from: Slide A sounds like a bunch of universal statements about (quoting the first line) "Rust threads". But Slide A and Slide B are really talking about different flavors of threads (especially concerning practical take-aways over technical truths). Let me try again to point out what I think is confusing in three passes of increasing detail. As a preliminary, I'm going to assume we could agree that while a waited-for thread might technically be a daemon thread, it doesn't really "matter" due to being waitied-for, because the parent thread will wait for the child thread. (I know there's more nuance here... but hey it's Day 4.) Pass 1: Typical usage, ignore handles, ignore panicsSlide A currently says:
Slide B currently says:
The question I, the student, asks in class:
Things I, the student, get confused and then annoyed at later:
Suggested change:
Pass 2: You still want to mention panics (but not payloads necessarily)Slide A currently says:
Slide B currently says:
Things I, the student, get confused and then annoyed at later:
Suggested change
(Also double-panics can cause an abort, even in child threads, but... nah, nevermind, it's Day 4.) Pass 3: You still want to talk about payloads tooSlide A currently says:
Slide B currently says:
Things I, the student, ask in class if I'm awake enough:
Suggested changes:
If you're worried about things being to complicated, I think this subtopic is optional, or mention-in-passing-not-in-detail. Though I personally think mentioning that you can avoid panic propagation in scoped threads is worth it, if you mentioned the panic tradeoff to begin with. In summary
You also asked, isn't the difference in borrowing ability the important difference? It's the motivating difference I agree, but I think that the difference in waiting and panicking are also important. If not, why even have the bullet points? (Additionally, they answer the question of why anyone would ever prefer spawned threads.) |
Thanks for all the comments and the thoughts put into them.
Right, I think we can be more consistent here! There is now also support for adding explanations to speaker notes via a simple Some of the things you discuss are things I live-code during the class: I normally show the use of |
I created #117 to help a bit with this (I'll leave this issue open since there is more we can do here). |
From the discussion in google#63.
I've significantly expanded the notes on this slide, which I think helps this situation some. I think the prose near "daemon threads" could be improved, though--I've written Unix programs for a long time and have never heard the notion of daemon (a program that double-fork to disassociate from its parent process and continues running in the background) used to refer to a thread. A google search suggests that this is a term exclusively used in the Java and Python communities:
Given that Rust threading is based on OS implementations, which are roughly standardized around pthreads, I think we should use pthreads terminology here ("detached thread") or simply explicitly state that the existence of other threads does not prolong the execution of the program past the end of Suggested prose:
More detailed discussion is present in the slide's notes, which I think are pretty clear. |
This is the last remaining fix left from #63.
This slide says that threads are all daemon threads, but this is untrue:
thread::spawn
created threads, as per the very next slideJoinHandle
spawn
ed thread, you calljoin
on the join handle to see if it panicked and to get the payloadSo you should talk about
JoinHandle
and detaching viaDrop
.On the scoped page you should talk about the different behavior:
ScopedJoinHandle
joins and blocks uponDrop
instead of detachingScopeJoinHandle
that witnesses a thread panic will causethread::scope
to panicjoin
and check for thread panics instead, similar toJoinHandle
Aside from the ability to borrow, this difference in handle drop behavior (and thus what may panic where) is the main difference between the two tools.
The text was updated successfully, but these errors were encountered: