"
A Pharo forked process is still running under the vm single threadedprocess... so it's more a matter of in-image blocking rather thanexternal access."
There is parallelism which means code that execute at the same time instruction by instruction ��
There is concurency which means code that executes a bit of it from different��parts giving the illusion that codes run at the same time
OS threads do parallelism
VM threads , aka green threads, do��concurrency
VM technically speaking uses several OS threads but the byte code is indeed executed on the main thread only , thus VM alllows only green threads for pharo code.��
I am not saying you do not know this stuff, I am just mention it here so everyone is on the same page.��
You cannot have more parallelism than cores, actually that may not be true because I think each core allows for two parallel��threads because of hyperthreading but more or less thats the idea.��
Just for the record there are cases when multiple OS threads running on multiple cores can be actually slower than one thread running on one core. This the nightmare that is called parallelism��and why coders generally avoid it.�� The usually reason why multiple��OS threads may be slower it has to do with CPU cache and how it exchanges data between threads and CPU cores.��
I had the pleasure of getting a taste of this nightmare when I was learning OpenMP which is the most popular library for parallel��execution for C/C++. Of course there are also the usual problems with synchronisation etc.��
Technically speaking you can do OS threads from Pharo with my CPP library. Thats possible because CPP works by having two isolated process (actually you can have an infinite amount of processes if your hardware can handle them ) , in this case one C++ executable and one for Pharo that share an area of memory that both can directly access to. You could implement callbacks to, you could do anything and you would not have to worry about joining threads or providing compatibility��with Pharo VM because you deal with shared data and not code execution.�� Because CPP uses shared memory which in turn uses OS kernel native memory access and management functions, you get top speed.��
So you can have one process using OpenMP taking full advantage of the hardware acceleration (triggering multiple OS threads) of your CPU cores and one for Pharo that will drive the OpenMP process.��
There is still the issue of data synchronisation, who locks the data and who accesses it at what time, but those are usual issues for any kind of thread orientated coding, you wont be doing anything diffirent.��
"However any CPU intensive request will block the process, and that
will happen with looping server like Pharo or an evented VM likeNodeJS."
Again you can avoid that with my CPP library. You do not need to block , you could let the external process do its thing and just block it when you decide to fetch data after it finishes or on specific intervals. There are so many ways you can do this. You can also have like the VM one central OS thread that is able to be blocked by Pharo and multiple secondary ones that Pharo will have no control over either than the level of control that the main thread provides.��
In any case, most servers run Apache which should deal with many of those issues, there are wrappers��for many languages , Apaches is wrriten in C/C++ so its should be able to tap into this technology to avoid solving problems that have been already solved. So its a matter of writing��wrappers for Pharo too.