71–76 of 76 posts
Earlier quoted context omitted.
Given the Universal Turning Machine and the Church-Turing thesis in actuality all of programming except for assembler is pretty much some API or language trick.
Arguably, even machine language is "some API" and assembler "some language trick".
Earlier quoted context omitted.
"My point is, move these IO actions to another thread; the code in that thread is good old synchronous/threaded code." Sure. But how do you handle that? IO results need to be communicated back to the UI thread somehow. Throwing together a whole new thread+stack against a named method that communicates back via explicit messages (or however you want to get the results of IO back to the UI thread) seems like a bit much…
There is no problem to modify UI state from any thread; just put up some synchronizations. The hard part is, if the modifications do not form a single, predictable, serialized chain, how can the programmer reason about them? This problem is independent of async/sync. If you use C# async for a UI action, you still need to worry about it.
Some UI APIs aren't thread safe and can't reasonably be made thread safe. They may even be kind enough to check the calling thread and intentionally throw exceptions (or otherwise abort) if invoked from a non-UI thread.
Hilariously, I've had to work around race conditions in such an API. Just because my access was forced to be on one thread, doesn't mean it's implementation was!
> The hard part is, if the modifications do not form a single, predictable, serialized chain, how can the programmer reason about them?"
Reusable async patterns can help you knock off the "single" and "serialized" bits of the microcosm you care about, leaving you to grapple with only the "predictable" one without the pointless "easy" boilerplate distracting you with additional complexity, line count, and bugs.
> If you use C# async for a UI action, you still need to worry about it.
Agreed. If you just spam the async and await keywords without understanding what you're doing, you're not magically going to get the benefits of a single, serialized chain of events. And they're not going to turn the inherently unpredictable response timings and contents of a series of web queries into a predictable one.
Earlier quoted context omitted.
Why buffer on the app server?
Because we have multiple app servers, but only one reverse-proxy? I don't want to centralize a task that could be distributed.
I don't write web applications, and I don't use much JavaScript, so it's very possible that I don't properly understand the motivation for this blog post. However, as others have said there is a difference between some inconvenient syntax in JS, and the fundamental model of non-blocking I/O. What I do write is lots of C/C++ client/server applications for HPC/HFT/DC workloads where speed both in req/sec (throughput) a…
Earlier quoted context omitted.
Of course it all depends upon the application. Processes are very heavy weight constructs. If you have a variable number of low-latency or lengthy tasks to do (streaming media, data reformatting, responding to external events) then threads are a good fit. Encapsulation is your friends. If each thread deals with a non-overlapping (set of) object(s), then many of the issues are gone. What is left is messaging between a…
Hmm. I don't think I made myself very clear. I failed to mention that I'm advocating 1 process per core, not hundreds (thousands) of processes. Over subscribing processes to cores has the same effect of oversubscribing threads to cores, which is suboptimal scheduling. Furthermore, this model allows you to easily pin work to cores (using process affinity) and to get all the juicy benefits of using cooperative scheduli…
Encapsulation saves you from threading nightmares. Your spaghetti notwithstanding. I've done this over 20 years and several startups, writing entire application environments on everything from embedded to desktop to server, and it works fine. Try it.
Earlier quoted context omitted.
Arguably, even machine language is "some API" and assembler "some language trick".
Good point, I forgot for a second that the CPU turns assembler into microcode before executing it.