[all-commits] [llvm/llvm-project] 40668a: [Support] Add a way to run a function on a detache...

[Sam McCall via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 40668abca4d307e02b33345cfdb7271549ff48d0
      https://github.com/llvm/llvm-project/commit/40668abca4d307e02b33345cfdb7271549ff48d0
  Author: Sam McCall <sammccall at google.com>
  Date:   2019-10-23 (Wed, 23 Oct 2019)

  Changed paths:
    M llvm/include/llvm/Support/Threading.h
    M llvm/lib/Support/Threading.cpp
    M llvm/lib/Support/Unix/Threading.inc
    M llvm/lib/Support/Unix/Unix.h
    M llvm/lib/Support/Windows/Process.inc
    M llvm/lib/Support/Windows/Threading.inc
    M llvm/lib/Support/Windows/WindowsSupport.h
    M llvm/unittests/Support/Threading.cpp

  Log Message:
  -----------
  [Support] Add a way to run a function on a detached thread

This roughly mimics `std::thread(...).detach()` except it allows to
customize the stack size. Required for https://reviews.llvm.org/D50993.

I've decided against reusing the existing `llvm_execute_on_thread` because
it's not obvious what to do with the ownership of the passed
function/arguments:

1. If we pass possibly owning functions data to `llvm_execute_on_thread`,
   we'll lose the ability to pass small non-owning non-allocating functions
   for the joining case (as it's used now). Is it important enough?
2. If we use the non-owning interface in the new use case, we'll force
   clients to transfer ownership to the spawned thread manually, but
   similar code would still have to exist inside
   `llvm_execute_on_thread(_async)` anyway (as we can't just pass the same
   non-owning pointer to pthreads and Windows implementations, and would be
   forced to wrap it in some structure, and deal with its ownership.

Patch by Dmitry Kozhevnikov!

Differential Revision: https://reviews.llvm.org/D51103