Liste des Groupes | Revenir à co vms |
On 9/30/2024 8:33 PM, Arne Vajhøj wrote:On 9/30/2024 8:24 PM, Lawrence D'Oliveiro wrote:On Mon, 30 Sep 2024 19:50:38 -0400, Arne Vajhøj wrote:>On 9/29/2024 11:15 PM, Lawrence D'Oliveiro wrote:>On Sun, 29 Sep 2024 22:34:04 -0400, Arne Vajhøj wrote:>But I am pretty sure that it will not work on VMS.>
That’s what I figured. VMS, like Windows, really wants you to use
threads.
For massive parallel processing on VMS then threads not
processes is the way to go.
Threads require shared memory, though. Processes allow you to have a mix
of shared and private data, plus the use of IPC mechanisms like message
passing. This makes for a looser coupling, which better suits the way
massively parallel systems are built.
It is undeniable that multiple processes are more loosely coupled
than multiple threads.
>
But efficiency is a problem. VMS does not do fork. Process creation
is expensive on VMS. None of that fancy moving descriptors over
Unix socket stuff.
>
VMS got plenty of methods for IPC. A solution with a fixed number
of processes doing IPC between each other may work fine.
>
But the concept of constantly starting new processes and killing
old processes is not going to perform great.
Well, now, that is a rather bold statement.Sometimes I make such.
Granted, starting up a new process involves some overhead.There are obviously a scale.
But it really depends upon the requirements. The more use out of a process once it is started, the better overall performance. If a group of worker processes is started once, then used for many tasks, then that overhead happens only once. Perhaps once a day, week, month, and even year. There are various communication methods available on VMS.
In the end, it comes down to the requirements. An engineer must evaluate the task(s) and determine what methods will give adequate results.
Les messages affichés proviennent d'usenet.