4 ms·

1) This is fair. 2) Explicit yield points certainly save you from most of the classic threading errors, and having to use special maps and datastructures every

1) This is fair. 2) Explicit yield points certainly save you from most of the classic threading errors, and having to use special maps and datastructures everywhere. 3) Other than tying into (1) I guess this is a matter of taste. 4) Supposedly this refers to the `open` function? This can be solved using the `aiofiles` module, but again I suppose this ties into (1).

nicolaslem 8y ago
> Explicit yield points certainly save you from most of the classic threading errors You know what also saves you from most classic threading errors? The GIL, and yet people writing multi-threaded code in Python still use locks and thread-safe datastructures, because most errors is not enough. Explicit yield points when the developer is forced to yield does not bring much more safety than executing normal Python bytecode.
Bogdanp 8y ago
Yes, a lot of it boils down to the ecosystem split for me. > 2) Explicit yield points certainly save you from most of the classic threading errors Can you provide an example of such a threading error? At most I've heard people claim that asyncio removes the need for mutexes[1]. I think that may be true at the local level, but as soon as your function needs to synchronize with other async functions in the system that ceases to be the case. At any rate, that's not enough of a win to justify the split in my opinion. > having to use special maps and datastructures everywhere. The GIL already protects you from corrupting builtin datastructures. Neither the GIL nor asyncio protect you from corrupting your data (the need for some form of synchronization), however. > 4) Supposedly this refers to the `open` function? This can be solved using the `aiofiles` module, but again I suppose this ties into (1). And most operations on opened files (like `read()`) as well as any OS bindings provided by the `os` module. [1]: Clearly, asyncio itself still thinks they're useful: https://docs.python.org/3/library/asyncio-sync.html#asyncio.Lock https://docs.python.org/3/library/asyncio-sync.html#asyncio....
shrimpx 8y ago
Wrt (2): Personally I find coroutine programming to be unintuitive and often lead to unreadable code, where the control flow is hard to reason about. Additionally, it introduces the honestly idiotic programming task of profiling to find chunks of code that "don't yield enough" and then breaking them up to yield more. The possibility is always there that some engineer on your team will commit some nasty blocking API handler that stalls your endpoint. Threads don't have any of these problems. Conceptually they are sequential code. You just have to clearly state what the communication model is between threads, and use a good one. The actor model works really well.
zzzeek 8y ago
> 2) Explicit yield points certainly save you from most of the classic threading errors, and having to use special maps and datastructures everywhere. "classic threading errors" don't apply to the users of a web framework where you are programming logic that shares nothing with other threads. Additionally, the most free-of-race-conditions monolithic application loses all of that advantage the moment it is placed in a multi-process environment, where other copies of it on the same host or other hosts are competing for the same resources. There is no non-trivial web application today that is deployed to production in a single process on a single host only. Web applications are not scaled vertically.
- mixmastamyk 8y ago
  > Web applications are not scaled vertically. Should be rare, but believe stackoverflow was doing that for a while.

nicolaslem 8y ago

> Explicit yield points certainly save you from most of the classic threading errors You know what also saves you from most classic threading errors? The GIL, and yet people writing multi-threaded code in Python still use locks and thread-safe datastructures, because most errors is not enough. Explicit yield points when the developer is forced to yield does not bring much more safety than executing normal Python bytecode.

Bogdanp 8y ago

Yes, a lot of it boils down to the ecosystem split for me. > 2) Explicit yield points certainly save you from most of the classic threading errors Can you provide an example of such a threading error? At most I've heard people claim that asyncio removes the need for mutexes[1]. I think that may be true at the local level, but as soon as your function needs to synchronize with other async functions in the system that ceases to be the case. At any rate, that's not enough of a win to justify the split in my opinion. > having to use special maps and datastructures everywhere. The GIL already protects you from corrupting builtin datastructures. Neither the GIL nor asyncio protect you from corrupting your data (the need for some form of synchronization), however. > 4) Supposedly this refers to the `open` function? This can be solved using the `aiofiles` module, but again I suppose this ties into (1). And most operations on opened files (like `read()`) as well as any OS bindings provided by the `os` module. [1]: Clearly, asyncio itself still thinks they're useful: https://docs.python.org/3/library/asyncio-sync.html#asyncio.Lock https://docs.python.org/3/library/asyncio-sync.html#asyncio....

shrimpx 8y ago

Wrt (2): Personally I find coroutine programming to be unintuitive and often lead to unreadable code, where the control flow is hard to reason about. Additionally, it introduces the honestly idiotic programming task of profiling to find chunks of code that "don't yield enough" and then breaking them up to yield more. The possibility is always there that some engineer on your team will commit some nasty blocking API handler that stalls your endpoint. Threads don't have any of these problems. Conceptually they are sequential code. You just have to clearly state what the communication model is between threads, and use a good one. The actor model works really well.

zzzeek 8y ago

> 2) Explicit yield points certainly save you from most of the classic threading errors, and having to use special maps and datastructures everywhere. "classic threading errors" don't apply to the users of a web framework where you are programming logic that shares nothing with other threads. Additionally, the most free-of-race-conditions monolithic application loses all of that advantage the moment it is placed in a multi-process environment, where other copies of it on the same host or other hosts are competing for the same resources. There is no non-trivial web application today that is deployed to production in a single process on a single host only. Web applications are not scaled vertically.

mixmastamyk 8y ago
> Web applications are not scaled vertically. Should be rare, but believe stackoverflow was doing that for a while.