Concurrency primitives and interfaces?

[maxfischer2781]

The design of asyncstdlib currently avoids relying on any concrete concurrency primitives – such as sleep or Event – to be event loop agnostic. This means that the toolbox can be used with concurrency but doesn't provide any by itself. While that is sufficient for mirroring the (synchronous!) standard library, there are some natural extensions – such as concurrency safety as in #86 or internal concurrency as in #76 – that would be useful for an async toolbox.

Technically, this could be approached by having a small set of concurrency primitives for which asyncstdlib defines the interface and event loops must implement it. The implementation to use would be swappable via threading.local/contextlib/...; so asyncstdlib just defines how to plug into things and perhaps an asyncio implementation and the rest is optional/third-party.

Some food for thought and notes:

• Should this actually be in asyncstdlib? A quick review of mine:

  • This might go well outside the current scope of being an unoppiniated standard toolbox, so a separate library might be worthwhile.
  • There is anyio as an asyncio/trio agnostic async framework already. Skipping the actual I/O and task APIs and focusing on high-level algorithmic primitives might be worthwhile.
  • There is sniffio for a low-level cross-event-loop framework. This might be an optional dependency to automate event loop discovery; there is no need to have every event loop implementation put a piece of code into asyncstdlib.

• What are the key event loop architectures to have in mind? The major ones I am aware of:

  • asyncio: Uses Futures as the basic event-like primitive. Uses suspension only (?) for task switching; cancellation is incidental.
  • trio: Uses an ambient scheduler and indefinite suspensions. Uses supension for task switching and cancellation.
  • curio: Uses an direct scheduler and indefinite suspensions. Uses supension for task switching, commands and cancellation.

• What are the reference primitives? Based on my trials so far:

  • Some Task-like form of adding concurrency.
  • Some Event-like means to notify many other tasks.
  • Some Lock-like means to notify a specific task.
  • Notably, these are not safe in that they can leak exceptions and activations. Perhaps there is a more robust set.

• What are pain points to consider? Some examples that I have struggled with:

  • Interrupts! Every async exception that does not cleanly cancel a task seems brittle. Various frameworks use them for timeouts at intra-task resolution.
  • Effect scopes. Things like trio Nurseries assume they "scope" the current call stack; yield makes that fall apart since we have a call tree in reality.
  • Task ownership. Used to propagate exceptions when a task fails. Nurseries get us half-way there, but there are concept like shared ownership that go beyond that.