Hacker News Reader

Comment by lrossi | Hacker News Reader

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.

It's difficult to get the point across on the Internet, but lrossi's statement is just nonsense. std::jthread has not introduced any new risks with respect to locking.

You are right, the sleep functions apply only to “this_thread”. What confused me is the comment for the two functions, which refer to the thread as “t” and not “this_thread”; which also matches the naming used for the “is_joinable” function, where it is not the current thread.

So I thought it’s a way to do back pressure across threads, which could be useful, but I was clearly wrong. My bad, but also not a great choice of naming things in the original article.

Then again, if you can only put the current thread to sleep, why have a function for it? Why not call sleep directly?

There's a proposal to add fibers (akin to Boost.Fiber) to std C++, and of course, don't forget about coroutines :-)

Reply on news.ycombinator.com