std::shared_ptr<coro::scheduler>

[edwardbr]

Hi I have been using a fork of your library for about a year. It is excellent although changing the scheduler factory to a coro::scheduler::make_unique for most use cases works unfortunately for me it breaks my code. I can move it though to an std::shared_ptr, but I need to tweak your server and client classes to make it all work.
I have a dynamic RPC library https://github.com/edwardbr/Canopy where many components need access to the same scheduler. Also there could be more than one scheduler and no one component is guaranteed to outlive another. Also I would prefer not using global static variables.

May we extend client to have an additional constructor

explicit client(std::unique_ptr<coro::scheduler>& scheduler, net::socket_address endpoint);
+    explicit client(std::shared_ptr<coro::scheduler> scheduler, net::socket_address endpoint);

And the same to the server:
```
explicit server(
std::unique_ptrcoro::scheduler& scheduler,
const net::socket_address& endpoint,
options opts = options{

        .backlog = 128,
    });

• explicit server(
  std::shared_ptrcoro::scheduler scheduler,
  const net::socket_address& endpoint,
  options opts = options{

     .backlog = 128,
  

  });

I have your code in a submodule with LIBCORO_FEATURE_NETWORKING enabled yet I have my own separate submodule for  c-ares.  Can we have these two lines optional in your CMakeLists.txt file?  As they cause problems too:

    add_subdirectory(vendor/c-ares/c-ares)
    target_compile_options(c-ares PRIVATE -w)

[jbaldwin]

Hello @edwardbr

For context the project originally used unique ptrs for the executors. I tried shared ptr for a while but then ultimately moved back to unique ptr due to the undeterministic nature of which thread would ultimately delete the scheduler or thread pool. On shared ptr lots of tests would frequently segfault when a coroutine thread on the thread pool or scheduler would end up doing the delete. If I remember correctly the segfault was usually one of the worker threads self joining in the executors destructor.

In theory the executors destructor could check and make sure the thread in the destructor isn't the thread it's joining and just skip that join, but I am not confident there are not other problems with the inderministic delete using shared ptr. It's fairly hard to reason about, whereas pinning the exector to main or a global is quite simple (in theory anyways). I'd be curious to understand why your use case cannot or doesn't currently have the capability to reference schedulers created with the lifetime of the program? I'm also guessing your use case likely works well if your program is long lived especially if the executors in shared ptr don't destruct until program completion, but perhaps you might occasionally see issues on shutdown? I'm speculating based on what I experiencedwheb libcoro executors were behind a shared ptr, so I would like to hear your experience if these issues I had you are not running into.

---

I'd welcome a PR change to make c-ares be an external dependency if you want to create one.