Re: Python (was Re: I did not inhale)

On Sun, 18 Aug 2024 18:13:37 +0200
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> boringly babbled:

On 2024-08-18 17:45, Muttley@dastardlyhq.com wrote:

On Sun, 18 Aug 2024 12:19:10 +0200
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> boringly babbled:

On 2024-08-18 10:30, Muttley@dastardlyhq.com wrote:
>

The windows process API is crippled which is why threading is the main
parallel processing method in Windows and has been since 3.0.

>
Threading is the main method because of its performance in a tight
coupled application. Crossing the process borders is very expensive.

 
Most (all?) versions of unix use copy-on-write when forking

>
You seems do not understand that spawning a process is not an issue of
interprocess communications. It is synchronization, e.g. events, mutexes
which is.

Huh? I'm talking about the cost of spawning a CoW process vs a thread.

Also shared memory is pretty cheap too.

>
Again, you need to synchronize in order to access shared objects, not to
mention elaboration of such objects, e.g. calling constructors and
destructors. With threads there is a linker support in most languages.
With processes you are on your own.

No idea what you're talking about. Wtf have constructors and destructors
got to do with forking a process? A process fork involves creating a new
process table entry with a copy of all the parents memory page pointers and
thats pretty much it, until the child process starts to change some page data
then CoW kicks in.

In the same library you might find portable implementation of basic
communication objects and compare Windows vs Linux vs BSD implementations:
>
   http://www.dmitry-kazakov.de/ada/components.htm#12
>

No idea what the pages of all that crap is.

>
Hmm, if you ever dealt with networking applications you should have had
some idea...

I've probably written more network applications than you can imagine and
the networking functionality side - on unix - is usually pretty simple (unless
you have to use OpenSSL then things can get tricky). I don't know why you would
need all those pages of code just to handle sockets.

Windows sockets are not integers ,

>
Windows did many things wrong, but accessing file descriptors by numbers
is beyond even Windows. In Windows a file is an OS object. You access it
getting an opaque handle to. Note that a handle can be marshaled from
one process to another. Try that with process-local numbers!

Open sockets are inherited by the child process after fork(). No marshalling
nonsense required.

they can't be multiplexed with file
descriptors, pipes etc in a single call.

>
Of course it can. Windows overlapped I/O supports sockets.

Not last time I tried it (2019) it didn't.

Like what? Why does the OS need to manage "objects"?

>
Like a graphic context or a mutex. Things that leak if the process dies
unless the OS takes care of.

Unix uses X11 (or wayland if you're unlucky) for graphics - even MacOS with
XQuartx installed. When the process dies all its graphics contexts die with it
and the OS is not involved.

I'm not talking about now, I was talking about when NT came out. Learn to
read.

>
Honestly I do not know what you are talking about. The option to change
the scheduling interval existed in Windows NT.

*sigh* Never mind.

If you want to compare Windows vs UNIX API, create a table and list
commonly used process communication things. In the cells write the API
call. E.g. mutex, pipe, pulse event etc.

I have something called "a life" so no, I'm not wasting hours just to keep
some random poster happy. I'm sure someone has already done it and it can be
googled.