On Wed, 27 Jul 2022 06:43:45 GMT, David Holmes <dhol...@openjdk.org> wrote:
> > Does run_in_new_thread seem good enough? > > No, sorry, the fact it both runs and joins is a critical aspect. `run_async` > in `CompleteableFuture` just does the "run in new thread" part, whereas the > `get()` on the returned `FutureTask` provides the "join". So a function that > does both needs to make that clear in the name - and there is no nice > succinct name for that, so we get stuck with something like > `run_in_new_thread_and_join`. Or we just have ` startThread` and `joinThread` > :) `startThread` and `joinThread` is not the functionality that the tests need. The functionality that's needed is one that combines these two, so that's what I went with. An API without real users is harder to get right. I've looked into adding `startThread` and `joinThread`. But, the story is not so simple. Since now the context passed to `CreateThread` and `pthread_create` has to outlive the function, which means heap allocating, or asking the caller to stack allocate. I think a typical C API might have a `new_thread` and `delete_thread` to do the memory management. These functions could be folded into `startThread` and `joinThread`, and we'd rename those to `create_and_start_thread` and `join_and_destroy_thread` (I think it's important to signal to callers that allocation happens, so that the memory will be cleaned up by calling join as well), but at that point it feels like we're back where we started. The alternative being stack allocation. i.e. the caller declares a `THREAD` variable and passes a pointer to it to `start_thread`, which then uses that memory. This avoids the heap allocation, but adds more noise in the caller. Getting into that just feels like too much unneeded complexity at this moment. So, `run_in_new_thread_and_join` it is. ------------- PR: https://git.openjdk.org/jdk/pull/9599
