josuttis / jthread Goto Github PK

Hi there,

I have a simple question that comes to my mind out of curiosity. Why jthread does not inherit from the thread?

Thank you

LEWG suggested using the "request" and "requested" terminology to indicate that the operation is an asynchronous request to stop and that the operation is not stopped immediately.

Also, I think the name change from interrupt to stop is an improvement.

This then raises the question about what to name the methods.

Some possibilities to consider:

• stop_source
  • signal_stop() => request_stop()
  • valid() => stop_requestable() or stoppable() or can_be_stopped() (or just leave as valid())
  • stop_signalled() => stop_requested()
• stop_token
  • stop_signalled() => stop_requested()
  • stop_done_or_possible() => stop_requestable() or stoppable() or can_be_stopped() or can_stop_be_requested()

referenced at the top of source/Makefile

The stop_token header uses labels named load_state and check_state which need to be __uglified for use in std::lib implementations.

First off, jthreads are a very interesting proposal for the std lib, I hope you drive it home. Thanks for your work.

Having a means of collaboratively requesting a halt of a chunk of work doesn't end with jthreads. It would be immensely useful to be able to pass the stop_token to other parts of the library, particularily std algorithm. Currently the way to stop e.g. std::sort on a large array is to pass it a predicate that throws an exception when stop is requested. This approach has issues of its own: exception safety, the need to wrap all sort calls with such predicates in try blocks, not usable in codebases with disabled exceptions, etc. Not to mention treating a perfectly normal case in GUI programming (user clicked away and wants to see another item list) as exceptional is somewhat hackish.

Are there any plans to respect the stop_token in other parts of the standard library?

Is there any particular reason why jthread does not allow constructing with external stop_source?
Was this ever considered in the standards?
Can't see any problems with such constructor, so just curious why it isn't in the library.
Well, the only ambiguity case I can find is whatever to do if the stop_source is already stopped.

int main()
{
  std::stop_source s;
  std::jthread p1{s, [](std::stop_token t){ // (does not work)
    doWork1(t);                             // t = s.get_token()
  }};

  std::jthread p2{s, [](std::stop_token t){  // (does not work)
    doWork2(t);                              // t = s.get_token()
  }};

  s.request_stop(); // stop both threads.
}

Obviously, this is trivial example, but more realistic scenarios can be a thread group, or dependent threads, that may benefit a shared stop_source.

There's a bug in condition_variable_any2 that I don't think impacts the implementation of jthread. However this is such a complex subject that no stone should be left unturned.

~condition_variable_any();

Requires: There shall be no thread blocked on *this. [Note: That is, all threads shall have been notified; they may subsequently block on the lock specified in the wait. This relaxes the usual rules, which would have required all wait calls to happen before destruction. Only the notification to unblock the wait needs to happen before destruction. The user should take care to ensure that no threads wait on *this once the destructor has been started, especially when the waiting threads are calling the wait functions in a loop or using the overloads of wait, wait_for, or wait_until that take a predicate.
—end note]

That big long note means ~condition_variable_any() can execute before a signaled thread returns from a wait. If this happens with condition_variable_any2, that waiting thread will attempt to lock the destructed mutex mut. To fix this, there must be shared ownership of the data member mut between the condition_variable_any object and the member functions wait (wait_for, etc.).

libc++'s implementation gets this right: https://github.com/llvm-mirror/libcxx/blob/master/include/condition_variable

It holds the data member mutex with a shared_ptr<mutex> instead of mutex directly, and the wait functions create a local shared_ptr<mutex> copy on entry so that if *this destructs out from under the thread executing the wait function, the mutex stays alive until the wait function returns.

It seems that the examples have a license but not the reference implementation. I wonder what the license is. Public Domain? BSD/MIT? etc.

Hi there, just as a clarification, I think the license of the project should point to https://creativecommons.org/licenses/by/4.0/ if the project is really licensed under the Creative Commons Attribution 4.0 International License (similar to MIT).

At the moment the README is pointing to https://creativecommons.org/licenses/by-sa/4.0/ which is CC Attribution-ShareAlike 4.0 International (similar to GPL).

There's been a lot of discussion happening over the last few years about "structured concurrency", across a number of different languages – we even started a forum recently, with participation from folks designing Python, Kotlin, Java, Swift, etc. I just heard about this proposal, and it's very closely related to the kinds of things we're talking about. So, I figured I'd drop you an invitation to join in, if you like! I also made a post summarizing this proposal for folks there, and comparing it to how other languages have approached this, which you might be interested in:

https://trio.discourse.group/t/structured-concurrency-proposal-for-c-20/125

How different is the std::thread from std::jthread?
Does it make sense to change definitions for c++20?
Is std::jthread only under c++20?
I was able to compile std::jthread under c++17. Is it compatible with mingw.thread.h?

int main()
{
	auto token = std::stop_token{};
	auto thrd = std::jthread{[](std::stop_token){}, token};
	assert(thrd.get_stop_token() == token); // surprise

	return EXIT_SUCCESS;
}

Just small question regarding the intended way the jthread ctor is used, because that was shown to me today as an alternative and valid way to use a jthread. I think that should not be allowed or otherwise the explicitly supplied stop_token should be copied/moved into the jthread so that the assertion holds. Or else the result of get_stop_token() may "surprise" when used IMHO.

As far as I can tell std::stop_source::request_stop() was standardized without const qualification. (see eel.is or cppreference). However that function is const qualified in this reference implementation.

To facilitate migration to C++20 it should be removed.