Wann greifst du zu Threads, wann zu Prozessen, wann zu asyncio?

Nimm asyncio für I/O in großem Volumen, wo du tausende gleichzeitige Wartezustände in einem Thread willst, Threads für I/O-Arbeit, für die es nur blockierende Libraries gibt, und Prozesse für CPU-lastige Arbeit, die echte Kerne braucht. Die entscheidenden Fragen sind, ob die Arbeit wartet oder rechnet, und ob die Libraries, von denen du abhängst, ein async-Interface anbieten.

Meine erste Frage ist immer, ob die Arbeit wartet oder ob sie rechnet, weil diese Antwort das Werkzeug bestimmt. Warten auf Netzwerk oder Platte heißt asyncio, sofern die Client-Libraries es unterstützen, denn eine Event Loop hält problemlos zehntausend offene Sockets auf einem Kern und der Speicher pro Task ist winzig. Wenn der einzige verfügbare Treiber blockierend ist, nehme ich einen Thread-Pool, weil ein Thread, der in einem Socket-Read parkt, das Lock freigibt und praktisch nichts kostet. Rechnen heißt Prozesse, oder der Sprung in eine native Library, die das Lock selbst freigibt. In einem Service, an dem ich gearbeitet habe, hatten wir beides in einem Request-Pfad: einen async Handler, der mit gather auf sechs interne APIs auffächert, und einen run_in_executor-Aufruf um ein altes blockierendes SDK, das wir nicht ersetzen konnten. Diese Kombination lohnt sich im Interview zu nennen, weil die meisten echten Systeme gemischt sind. Der Fehler, auf den ich achte, ist, wenn jemand eine schwere pandas-Transformation in eine Coroutine packt, denn dann bedient die Loop während der Laufzeit nichts anderes mehr.