I’m just waking up and haven’t had coffee yet this morning, and I’m not an asynchronous programming guru, but I’m not sure I understand what this is for.
From the code snippet on the front page:
;; Wrapping in 8sync "suspends" this function, running
;; fetch-active-users asynchronously, and "wakes up" the function
;; when ready, seamlessly passing back its result.
How is that different than just blocking on the fetch-active-users call?
Presumably while that function is “suspended,” other functions can be active, including, but not limited to, fetch-active-users.
That’s just regular multi-threading, though.
Asynchronously structured programs are intended to allow concurrency within a single thread, either as an alternative or supplement to multithreading. Think nginx, node.js apps, libevent, etc. Within a single thread, you can handle high levels of concurrency with a model where you avoid blocking, instead letting other tasks execute until what you need becomes available. The execution is typically driven by events and callbacks: when you would have blocked, you instead register the rest of the work you need to do as a callback, to be called when the resource you need is available, and then just let the thread continue on to whatever else it needs to do. A top-level event loop then drives the execution by calling these callbacks as needed.
There’s a long-running debate over the pros and cons of the threading vs. async models. But if you are going to take the async approach, there’s also increasing consensus that the approach of pervasive, explicit callbacks gets unwieldy beyond simple programs, so there are various proposals for a better programming model. This is one of them that seems quite nice to me. C#’s async/await approach is another one, and ECMAScript 6 added something called promises.
Maybe read my question?
The code sample in the link, which I quoted, says the 8sync library calls the fetch-active-users function asynchronously and then blocks waiting for it, executing other tasks until the fetch-active-users call returns and wakes up. What’s the point in that case or the advantage over typical threads?
To me it almost sounds like it’s just a green threads library, using “async” to cash in on the hype around that.
It doesn’t block; “suspends” is in scare quotes, indicating that the programmer can write the function the same way as if it did. It registers a callback, same as if you had manually done that in node.js, except that the callback is generated automatically, using a delimited continuation to represent the function to be registered on callback. Green threads are more typically implemented by a VM that explicitly maintains a list of current executing (green) threads, implements context switching and scheduling between them, etc., rather than the event/callback style. But yes, there’s a rough equivalence between green threads and async programming, so any of these async programming models can be interpreted as a form or simulation of green threading.
That is pretty nice.