▲ 68 points
back
66 comments
Why an entirely new class? Why not just pass a constructor argument to specify joining behavior? It's not like there's any reason to believe this is the only thing we'll ever want to customize for a thread.
I don't think making blocking on destruction conditional is a good thing. For example futures returned by std::async block on destruciton as opposed to other futures (even if they have the same type). This is generally considered a mistake as the future behaves very differently depending on how it was created and it can cause issues (i.e. deadlocks) for code that did not expect the blocking behaviour.
As an aside I believe that all kind of blocking in a destructor (and thus jthread) is generally a mistake. In order of preference I believe that:
- enforce explicit join, abort or detach via the type system (hard to do in C++)
- abort the async computation
- abort the whole program (i.e. assert)
- detach the async computation
are all preferable to blocking. I think I'm in the minority though.
Could you elaborate on why blocking in a thread's destructor is bad? You mention it is but don't really give any reason. Every time I use std::thread I find the need to wait on it in the destructor. In fact any non-joining thread is a code smell to me. If you just detach (or abort...) a thread, then there's simply no way to ensure that main() will return after the thread has finished—and you always want to make sure all threads finish their tasks and clean up properly before the process terminates. This requires you to wait on threads during app shutdown, which generally corresponds with destruction, which means you need to join on destruction. I actually don't understand why you would want it another way by default (if at all).
I just think that blocking is an important enough effect that that needs to be accounted for and it should be explicit in code. Deadlocking is the obvious reason, but also the possibly large pauses are problematic.
I'm a big believer in crash-only software and I think that "clanup" at shutdown is code smell and a symptom of unreliable software [1]. Just call _Exit when the application is done.
[1] Cleaning up to decrease the noise for the benefit of a leak detector is useful though, but by experience, I'm not yet convinced that the effort is worth it.
Just last week I was debugging an issue with a library that used SQLite internally, and I noticed that whenever I shut down, it would leave all these "something.db-shm" and "something.db-wal" files around in addition to the "something.db" file. My hunch was the library wasn't properly deinitializing SQLite, and indeed that was the case, if you call sqlite3_close() properly, these files are deleted (they're essentially journal files for SQLite). The library was essentially doing what you're suggesting, ending without doing the proper cleanup.
Destruction, in general, is one of the most complex areas of software development in my opinion. You're right, blocking or throwing errors during destruction is terrible, but you really do have to genuinely clean things up when exiting, you can't leave messes behind like this. However, in addition to that: you can't ever count on destruction occuring, because it's entirely possible that your program crashes, the user kills the process, the computer runs out of battery (or someone janks the cable out) or some other random thing causes your process to exit prematurely.
You really need a lot of nuance in this area, and I don't agree with "cleanup at shutdown is a code smell". But you're certainly right that you can go too far in the other direction as well: destruction has to be fast, non-blocking, error-free, and never required.
> you can't ever count on destruction occuring, because it's entirely possible that your program crashes, the user kills the process, the computer runs out of battery (or someone janks the cable out) or some other random thing causes your process to exit prematurely.
Well yes, that's why you can't wait for shutdown time to cleanup your mess. In this case, either the files need to survive process exit or they can be unlinked as soon as they are created. Another option is to have very simple supervisor process whose only job is to cleanup.
For a DB like sqlite it does makes sense to have some amount of shutdown cleanup to close transactions and mark the log as stale and avoid any recovery on startup, but it should be considered an optimization and not be a requirement.
To make this short, I do in fact agree with your nuanced view. Pragmatism always trumps dogmatism in software engineering.
Yeah I'd argue these problems happen because people don't take advantage of RAII (maybe because they don't like it or their language doesn't support it), and then forget/neglect to do the proper cleanups at the correct time. You want to design things so that they encapsulate their correctness by design. For a thread, that means joining it on destruction (because that should happen in general). For a mutex, it means not unlocking it on destruction (because that signals another part of the code is actually incorrect). For lock guard, it means unlocking on destruction. For files, it means closing them on destruction. Etc. You can't just reduce everything to "always" or "never".
I think there are two schools of thought on this issue:
1. Blocking/unblocking is a major side effect, so it should be handled automatically so you don't forget about it
2. Blocking/unblocking is a major side effect, so it should be very prominent in the code so you don't miss it when reading, and it doesn't accidentally happen when you don't expect it
The C++ designers usually favor the first school, leading to designs like `std::lock_guard`. Many others, myself included, favor the second school, and would complain that the code marker that a method will block forever waiting for a thread to finish shouldn't be "}".
I would also say that in general blocking forever should not be the default - you should have to explicitly ask for it, not have it as a default. This could be achieved with a RAII design by passing the timeout parameter to the constructor, but that obscures the meaning of the } even more, especially if the thread ownership ever changes hands (a function receiving a std::unique_ptr<std::jthread> would wait an unknown amount of time on a }, for example).
The thing is, you talk about how blocking implicitly is bad, but I didn't say "it's good to block in the destructor" as a blanket rule either. I'm talking about this very particular case of blocking deserves to be in the destructor, for what I thought were fairly decent reasons that I spelled out. You haven't actually addressed my points about threads specifically and are just talking about blocking in a destructor in general, but the discussion/disagreement isn't about other cases. There are definitely times when I think it'd be wrong to block implicitly, but this just isn't one of them.
I think the arguments I presented do hold for thread joining as well as other cases: it's less clear from the code that this:
int main(int argc, char[][]argv) {
std::jthread t([](){
volatile int a;
while(true) a=1; });
}
int main(int argc, char[][]argv) {
std::jthread t([](){
volatile int a;
while(true) a=1; });
t.join();
}
//using the volatiles since while(true); is UB, nothing to do with threading
I've also asserted that the api of std::jthread::join is not great, that it would have been pereferable to have a mandatory timeout parameter, so that someone calling it would be forced to think about an appropriate timeout, since blocking forever is rarely the right choice (of course, you would have a constant for blocking forever as well - this is not about preventing this behavior, just slightly discouraging it).
If you agree that blocking forever waiting for a thread to join is in itself something to be discouraged (not made impossible, but also not the default), then it also follows that having a destructor block at all should also be avoided in the std lib.
I do want to emphasize that I'm not claiming that there are no cases where this sort of behavior is useful, just that it is more rarely the best choice. I also believe in the idea that language/library design should nudge users into the right direction, so that the better use case is also the easier one to write.
Not the parent, but mine is not a theoretical argument. I work on an highly threaded application. Many components spawn threads, send messages to other components running on other threads and wait for messages or events from other components. When you have base classes and members all blocking in their destructors is very easy to end up with deadlocks or race conditions just by changing the order of members or base classes and things like that.
By having an explicit (asynchronous) shutdown phase this can be avoided.
There have been some talk in the committee about having async destructors. That might be the solution to the problem.
So, I guess I fall in the middle.
I have no issues with lock_guard. Also, it will unlock on destruction, which is not much of a problem. And having this sort of side effect at end of scope is consistent with languages having synchronized or atomic blocks.
I would also not have much of a problem with a join_guard that joins one or more thread on destruction.
I am a fan of RAII and both lock_guard and join_guard have a single job and if you use them it is pretty obvious what you want, you can opt in on them and you can delegate the job by passing them around.
My issue is with more complex objects blocking on destruction when it is not their primary purpose.
In my opinion, when you have an internal boolean flag for two behaviors, the interface you should probably expose isn't the flag in one function, but two different functions.
edit I see I'm late, dataflow already made this point. I'll leave this here anyway.
This rule of thumb is often useful but there are many exceptions.
As an example, the internal behaviour of this OpenCL function [0] is presumably quite different depending on which bits of the second parameter are set, but it's still a good design as all possible behaviours of the function are still closely related as far as the user is concerned.
[0] https://www.khronos.org/registry/OpenCL/sdk/1.2/docs/man/xht...
But you made the point much better than dataflow. Their comment is borderline incendiary.
And yes there are exceptions, that's why my comment had so many rhetorical devices to defuse those silly arguments. My comment is specifically about "booleans and two behaviors" and even then I don't affirm it as the only valid way, only as my opinion and not in all cases.
Come on... I made a point in my first comment, you either miss or ignore it, I cite an example to maybe get it across in case it's more vivid with a obvious example, and instead of at least acknowledging the point and maybe disagreeing with it, you ignore it and say it's "incendiary" and "silly" to post such a vivid example? The counterexample isn't some weird exception; it's quite typical, and especially pertinent for this particular case.
The point I've been making is: std::thread is an absolutely terrible candidate for something that you can expect to only have "two behaviors" moving forward. This isn't even a prediction; you just have to look at current platform APIs to see this. I'd cite Windows's CREATE_SUSPENDED as one example of another flag you might want, but someone would inevitably complain and tell me that's just the Windows API being unnecessarily overcomplicated. So, instead, go ahead and check out the sheer behemoth that is POSIX's "simple" interface: the pthread_attr API used to specify different behaviors for pthread_create. It's not just a flag, it's not just a struct... it's a list of structs where each one contains flags as well as other things. And Linux's clone() is the other extreme, where they pack a gazillion flags (read: behaviors) into one integer parameter for thread creation where you'd think it'd leave a little more room for extensibility. Thread creation isn't just something that might need "more than two behavior", it's pretty much the diametric opposite of "two behaviors" if I've ever seen one!
I did not say what you said is "incendiary", I said it is "borderline incendiary". It's not incendiary since it is true, but it is expressed in such a pythy fashion as to be almost incendiary. Especially when I crafted my original comment to specifically acknowledge those cases.
Between your answer and MaxBarraclough's, one is tonally a quickwitted mean quip and the other is a well articulated and well meaning response.
A strategy template parameter works well in this case - parameterize the type.
I'd disagree on that. That would create 2 unrelated types when in fact one of the classes here semantically really is more like a subclass of the other one. Additionally, that creates additional work for the compiler both for this class (makes it hard to put the definition in an implementation file) and for its users (containers will now get instantiated and codegened for each type separately).
So like std::ios_base::fmtflags should actually be 19+ different functions and/or classes?
That isn't a boolean flag.
Each bit is a Boolean flag (hex, scientific, etc.)... they're just packed into an integer. (Nobody said you have to use N bools for N different flags...)
The main reason is so that the type system knows which thread is which and can handle it differently.
They may still inherit from the same implementation and do what you suggest though.
> The main reason is so that the type system knows which thread is which and can handle it differently.
Why is this useful in this case, is my question. You can try to put lots of things into the type system that aren't, but that doesn't automatically make them better. In fact I'd argue it makes things worse here, e.g., now every container will be instantiated twice depending on whether you use jthreads or threads, almost doubling the amount of work the compiler has to do for them.
It's useful because you may be able to make compile-time decisions on the basis of the type of thread you're dealing with. What those are, I don't know.
As for instantiations, an astute library developer will be able to do the right thing. It's not that hard.
say you have function that returns a thread object (which is perfectly fine as std::thread is moveable). The caller cannot assume that the thread will join on destruction and needs to conservatively join or detach explicitly anyway.
Re container, they will only be instantiated twice if you actually use both std::jthread and std::thread of course. The idea (which I disagree) is that jthread is the better solution and std::thread is sort of deprecated.
> The caller cannot assume that the thread will join on destruction and needs to conservatively join or detach explicitly anyway.
This seems a little backwards to me? If the thread should join on destruction then that flag should be set. If not then it should be clear. I'd argue that flag should probably be set in general (and it seems you might feel the same way), but if you have a reason to clear it, then you're just fighting your own program by ignoring it.
> Re container, they will only be instantiated twice if you actually use both std::jthread and std::thread of course. The idea (which I disagree) is that jthread is the better solution and std::thread is sort of deprecated.
Good point!
> The main reason is so that the type system knows which thread is which and can handle it differently.
Except that's not really the case: std::thread is joinable as well. The difference between the two is what happens in the dtor, respectively "terminate" and "join".
Yes except when given a std::thread you don't know whether it will join in the destructor whereas with jthread you do.
I personally don't know how it helps. But I'm sure the proposals had some reasoning.
> I personally don't know how it helps
I really don't think it does personally. You can argue one way or the other with respect to safety (and I would very much agree that terminating on drop is insane), but that's really your backstop, and it's not really relevant to the person who is given a thread: they should know what they want to do with it, and if they want to join it they ought do so.
Joinable thread and non-joinable one are very different in usage. It is rather appropriate to use a different class.
> Joinable thread and non-joinable one are very different in usage.
What is the usage of a "non-joinable" thread in the first place? I mentioned in a comment that that concept itself seems like a code smell to me, and certainly not something that should be the default. See here to read why: https://news.ycombinator.com/item?id=26142754
std::thread are already joinable (and that's their default state), and jthreads can be detached.
The one difference between std::thread and jthread is that std::thread terminates on destruction, while jthread joins. That could easily be a ctor parameter (as well as "detach on destruction" as a third option).
Because std::jthread adds new methods as well. If you don't use a different class, then you end up with a weird situation where you still have to decide what get_stop_source() and get_stop_token() should do when the new constructor argument is omitted. That's definitely less clean, IMO.
I mean, you can just throw an exception or leave it undefined when the state isn't what you expect... isn't that a normal thing with any nontrivial class? e.g., what should unique_lock do if you call lock() when you passed adopt_lock_t to the constructor? What should unique_ptr do if you call operator->() when you passed null to the constructor? What should fstream do if you call open() when you already passed a file name to the constructor? etc.
This is a considerably better discussion of std::thread and std::jthread:
A little disappointing. I was hoping to see lightweight thread behavior or other lessons learned from Go.
The ability to pause a thread from outside is interesting, but it doesn’t seem very useful in general.
It also comes with risks. What if it’s holding a lock? That could cause a performance/latency disaster.
Lightweight threads like in Go or Erlang are not happening anytime soon as a C++ standard because they require much more complex runtimes to be decently implemented (whereas traditional threads can just delegate straight to whatever OS threading is available).
There are coroutines though, that can fill some of the same needs covered by lightweight threads: https://en.cppreference.com/w/cpp/language/coroutines
C++20 also includes coroutines, which can be used to implement lightweight async behavior without the overhead of a thread.
Any function that returns while holding a lock may be a disaster. That's not specific to threads. This is why you should prefer RAII locked mutexes like std::scoped_lock whenever possible.
What you say is true, but (as far as I can tell) unrelated to the issue at hand. Yes, if you return holding a lock, it's a potential disaster. And if you pause a thread from outside while the thread is holding a lock, it's a similar disaster. But RAII and scoped_lock won't save you if a thread is paused from outside, since the paused thread never makes it out of the scope that took the lock.
You are talking about some theoretical thing that doesn't apply here. There is no facility in std::jthread that allows it to become "paused".
Then what was lrossi referring to when he (?) said:
>>> The ability to pause a thread from outside is interesting, but it doesn’t seem very useful in general.
>>> It also comes with risks. What if it’s holding a lock? That could cause a performance/latency disaster.
Which you replied to, not claiming that it couldn't be paused from outside, but instead that the lock risk was just the same as returning from a function.
There's a proposal to add fibers (akin to Boost.Fiber) to std C++, and of course, don't forget about coroutines :-)
I think a relevant link is https://trio.discourse.group/t/structured-concurrency-propos...
Just remember: when you use C++$latest features in your code, you won't be able to distribute, compille and run it on an distro older than a handful of years. That is to say: almost all of them.
Why not? Of course you need an up-to-date compiler, but beyond that I've never heard of any fundamental issues in compiling binaries that work on older systems (well besides installing newer compilers or cross-compiling being a real PITA to set up on Linux sometimes, but that has nothing to do with language features).
Replacing the compiler on a distro is not a simple task and it has system wide consequences that make it very undesirable for continued system stability.
Yes, you can try compiling everything static and then distributing the fat binary. It might work on most systems. But if it's dynamically linked then it'll fail with libc++ errors locally (local libc++ not having c++$latest support).
Why can’t you install multiple versions of the compiler on the system? This seems like a poor design choice that could be easily solvable if you move outside the “only run what the distribution blesses” idea.