# Docs

* More examples
  - Including comparison with other methods, like threads, plain futures,
    futures-await, etc.

# Panicking/unwinding

* Coroutine::scoped & Coroutine::main

# Interface

* Something like select?
* Wait for future with timeout?
* Iterator that leaves the rest there on break
* Scoped spawns (so the data passed inside the closure don't have to be
  'static). Maybe call it join?
* Accept None as handle and spawn our own. Or, allow even others executors.
* Access to the builder that created this coroutine, so we can spawn with the
  same config (and provide default if we're not inside a coroutine)? This could
  be handy for libraries.
* Include some logging.
* Make „eagerness“ of start of the coroutine configurable (eg. do we schedule
  it to run later on, or execute it right await and stop the parent while it's
  running).
* Cleanup control: add more than just leak_on_panic (always leaking, directly
  aborting, etc).
* corona::io::BlockingWrapper could use some more methods, to expose the inner
  stream.

# Threads

It's impossible to do proper N:M threading scheme in Rust (or it seems). But it
*is* possible to pick a thread at coroutine creation and let it live its whole
life there.

There are questions, though:

* We probably want to have this as feature gate. Do we want to provide „dummy“
  implementation that doesn't go into background thread if not enabled?
* What is the preferred way? Have our own thread pool for coroutines, with
  lazily (or configurable-started) threads, and using thread futures-cpupool
  for the futures we wait for? Or have a core (or another executor) in each of
  the threads to place them there?
* Have a one, global pool or something like per-builder?
* Automatically send waited-on coroutines to the futures-cpupool if they're
  send?

# Misc

* Make the waits without allocating
  - Have a (handle-local) `FuturesUnordered`
  - Each coroutine pre-allocates one future in there.
  - The content may be either empty (the coroutine isn't waiting on anything),
    a pointer to the actual waited-on future (on the coroutine's stack) or Done,
    at which point it'll resolve.
  - We need to switch the content and notify it when needed.
  - There are some challenges with ensuring we know pointers both way and that
    nothing gets used after freeing. If possible without too many levels of
    indirection. Maybe something could be allocated at the bottom of the
    coroutine's stack?

# Tests

* Does it make sense to do some kind of fuzzying? How would that work, spawning
  random coroutines that randomly do something and yield?

# Tokio porting

* Allow specifying handle to the runtime/executor (and use the default one by default).
