Comment by netbsdusers | Hacker News Reader

Comment by netbsdusers | Hacker News Reader

Parent Full thread

I am surprised by some of the comments claiming to find it very hard to make an async API out of a sync one.

I write a hobby kernel with a profoundly asynchronous I/O system. Since it's nice to have synchronous I/O in some places (reading in data in response to a page fault, for example, or providing the POSIX read/write functions), I have to turn it into synchronous I/O in some cases.

Asynchronous I/O notifies its completion in a configurable-per-I/O-packet (called "IOP") way. The default is to signal an event object. You can wait on an event object and when it's signalled, you're woken up. The result is that synchronously sending an IOP is hardly any more work than:

  iop_send(iop);
  wait_for_event(iop->completion_event);
  return iop->result;

I would be surprised to hear of any system where you can't do similar. Surely any environment has at least semaphores available, and you can just have the async I/O completion signal that semaphore when it's done?

I don't think the problem comes so much from async v. sync, it comes from the implementation language/framework.

If you were to wait_for_event (or its equivalent) in the node main thread you will stall the 1 thread handling requests.

This whole problem is not just async/sync, it is the environment you live in.

What we should be questioning is why high level languages in high level frameworks make the programmer even consider the distinction at all.

If I am handling an http request, the async nature of this is an optimization because threads (or worse, processes, I once easily dos'ed an apache system that created a new process for each request) are too expensive at scale.

It should not concern the programmer whether a thread is launched for each request or we are using cooperative multitasking (async). The programmer/application needs that information from that call before that one piece can move forward.

The lower level async-as-state-machine (or coroutine or whatever) should be more standard, but that's an argument for another day. For now, you're right and the opaque threading model is basically what Go does. On the other hand, it's not suitable for Rust because in some ways Rust is lower level. C# went and did it the Rust way, which I personally appreciate but I understand fits into the problem you're describing.

Reply on news.ycombinator.com