4 ms·
Only in poorly designed code you have problems like this where Async Await goes viral. It can be avoided by spiting libraries into an IO part that uses Async/Aw
by mzimbres 2y ago
Only in poorly designed code you have problems like this where Async Await goes viral. It can be avoided by spiting libraries into an IO part that uses Async/Await and a protocol part that is sans-io. Using async code to access data that is already in the application memory is inefficient and should be implemented synchronously with regular functions instead of asynchronously.
- gpderetta 2y agoThis seems a no true Scotsman argument. In actual real applications it is not always possible to split IO from non I/O parts and the virality of async prevents composition and encapsulation without significant refactoring.
- mzimbres 2y ago> In actual real applications it is not always possible This depends on what are your expectation. IO operations must suspend to wait for data read and writes, therefore it is not possible to avoid Async/Await. In other cases you might have multiple tasks depending on a specific IO operation, for example, one connection to a database that is used by multiple HTTP sessions, here it is also not possible to avoid Async/Await because those sessions are bound to an IO operation. The real problem however comes when tasks that can complete synchrously are implemented with an asynchronous interface, for example message = Await websocket.read(socket, buffer, ...) This is a poor design because a socket read can pull multiple messages from the kernel buffers into user space and there should be a way to consumed them without Await. Many libraries however don't for watch this problem and that results in the everything is async madness.