To answer your second question.

The main advantage Coro, has, is lighter weight execution contexts.

For your stated requirements, 3000 to 12000 threads, unless you are running on some massively parallel hardware, your problem must be IO-bound rather than CPU-bound. Even on one of AMD 48-core motherboards, running 3000/12000 CPU-bound threads would involve so much context switching that you would waste a huge portion of your overall clock cycles.

For IO-bound applications where you have (say), large numbers of concurrent tcp conversations that spend most of their time waiting for responses, Coro is probably your better bet.

Though, if you have multiple cores, your application will be limited to using only one core at a time, which may prove limiting.

Perhaps the best solution would be to run a Coro scheduler instance inside each of multiple threads--one per core--and split your conversations between them. This still has the limitation that only a single conversation within a given Coro instance will be able to be run concurrently; but will allow concurrency by conversations in different groups.

It is also unclear whether the underlying libcoro library is thread-safe. If it is, ithreads will have no problem running those multiple instances, but it is a big if.

I'd love to see a high-level description of the task that requires 3000 to 12000 threads?