libev VS microjob

Thank you for this.

I am interested in how concurrency can be represented elegantly and efficiently, so I am interested in how libraries can simplify async and make it easier to reason about and write

The libev and ioring support is great for IO scalability (https://github.com/enki/libev not sure if this is the official repo)

In Python I use the "select" module and use epoll on Linux.

I am currently thinking of designing an API that allows the registration of epoll-like listeners to arbitrary objects, including business objects, so you can efficiently register a listener on multiple behaviours of multiple arbitrary objects.

I wrote an async/await simulation in Java and my scheduler is really simple, it's just a for loop that checks to see if there are any tasks that can progress. I notice the switch_fiber in polyphony must do something similar. This is similar to a yield in a coroutine.

My async/await simulation takes the following program:

  task1:

Also, libev

It's done even now. See ev.h where they do this. Just that you disable GCC's aliasing warning. There's a reason why restrict and aliasing became important to deal with. It wasn't standards that killed it.

node.js is multithreaded under the hood and always has been. It's true that we used to not have multi thread capability as developers, but we actually have for several years now, but most developers have probably never used it. Even prior to Worker Threads/Shared Buffers, we had 3rd party modules such as node-fiber and various shared memory data structure libraries which could be used to build multi threaded javascript programs. https://github.com/wilk/microjob <- dead simple batteries included multi threading in node.js

Real life example: We wanted our website to be static files to save on system time as a kind of caching strategy. So far there are about 100 pages that need to be rendered sometimes when there is an update to the site. Running all of this through our templating engine at once caused the node server to be unresponsive for about 30 to 40 seconds. No joy. There are a few ways to solve this but the one we decided on was to use web worker threads for this execution because this was not going to happen very often. About 5% to 10% of the time. It basically just puts this function (rendering all of the pages) into another thread and returns the result. Now this takes about 15 to 20 seconds and does not hold up the main thread. We used a library called Microjob that makes using a web worker really easy https://github.com/wilk/microjob