In comp.unix.programmer Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Sometimes, there seem to be some choices how to do something in
> Python.

Of course. The slogan is just, well, a slogan, not to
be taken 100% literally. For example, there are almost
always some choices to be made whether to use
object-oriented features or not.

Some years ago I wrote a simple but useful Python
script for searching eBay items. It is so
simple that no classes are really necessary, one
could use just dictionaries/hashes instead. But for
some sanity, I think I used a class or two to
make things a bit better organized and self-documenting.

The last I checked, the O'Reilly Python book is just
absolutely *MASSIVE*. The language has a huge number
of features now and it is pretty obvious that choosing
which ones to use can be a matter of preference. So
there is no "One True Way" to choose.

I guess this is not much different from C++ which proclaims
to be multi-paradigm, but nobody ever uses the immense
full feature set. I've been told that all serious
C++ programming teams stick to a subset of features
that are allowed to be used.

br,
KK

On Thu, 15 Aug 2024 19:48:36 -0000 (UTC), Kalevi Kolttonen wrote:

> The last I checked, the O'Reilly Python book is just absolutely
> *MASSIVE*. The language has a huge number of features now ...

No, it hasn’t. The core language reference spec is only a small fraction
of, say, the Java language spec.

It’s just that you can do so many things with Python. And that is down to
the huge variety of off-the-shelf addon libraries that build on that core
language spec. It has to be a strong, very solidly founded core in order
to be such a versatile basis for these addons, and it is.

On 2024-08-15, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 15 Aug 2024 19:48:36 -0000 (UTC), Kalevi Kolttonen wrote:
>
>> The last I checked, the O'Reilly Python book is just absolutely
>> *MASSIVE*. The language has a huge number of features now ...
>
> No, it hasn’t. The core language reference spec is only a small fraction
> of, say, the Java language spec.
>
> It’s just that you can do so many things with Python. And that is down to
> the huge variety of off-the-shelf addon libraries that build on that core
> language spec. It has to be a strong, very solidly founded core in order
> to be such a versatile basis for these addons, and it is.

That's idiotic; you're saying that the standard library packages of
Python are not part of Python, and do not contribute to its size.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

In comp.unix.programmer Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 15 Aug 2024 19:48:36 -0000 (UTC), Kalevi Kolttonen wrote:
>
>> The last I checked, the O'Reilly Python book is just absolutely
>> *MASSIVE*. The language has a huge number of features now ...
>
> No, it hasn’t. The core language reference spec is only a small fraction
> of, say, the Java language spec.

Okay. I must confess that just seeing the book's size discouraged
me from buying or reading it. Programming Python, 4th Edition by
O'Reilly has whopping 1628 pages! This has to be one of the longest
programming books ever published.

> It’s just that you can do so many things with Python. And that is down to
> the huge variety of off-the-shelf addon libraries that build on that core
> language spec. It has to be a strong, very solidly founded core in order
> to be such a versatile basis for these addons, and it is.

So are you saying that most of the 1628 pages describe libraries
instead of the core language?

br,
KK

In comp.unix.programmer Kaz Kylheku <643-408-1753@kylheku.com> wrote:
> On 2024-08-15, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Thu, 15 Aug 2024 19:48:36 -0000 (UTC), Kalevi Kolttonen wrote:
>>
>>> The last I checked, the O'Reilly Python book is just absolutely
>>> *MASSIVE*. The language has a huge number of features now ...
>>
>> No, it hasn’t. The core language reference spec is only a small fraction
>> of, say, the Java language spec.
>>
>> It’s just that you can do so many things with Python. And that is down to
>> the huge variety of off-the-shelf addon libraries that build on that core
>> language spec. It has to be a strong, very solidly founded core in order
>> to be such a versatile basis for these addons, and it is.
>
> That's idiotic; you're saying that the standard library packages of
> Python are not part of Python, and do not contribute to its size.

You seem to have a point. The core of C language is also small. I
guess they even said in the original K & R book that C is a small
language best described by a small book.

But in order to do anything with C, you need to know the standard
libraries. They have grown bigger and bigger during all these
years. One could also well argue that to program on UNIX, you also
need to know all the POSIX libraries.

So it is indeed a vague question of what belongs in given programming
languages.

br,
KK

On Fri, 16 Aug 2024 15:02:20 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:

> You seem to have a point. The core of C language is also small. I
> guess they even said in the original K & R book that C is a small
> language best described by a small book.
>
> But in order to do anything with C, you need to know the standard
> libraries. They have grown bigger and bigger during all these
> years. One could also well argue that to program on UNIX, you also
> need to know all the POSIX libraries.

What you *need* is also very much dependent on what you need to *do.*
If all you're doing is batch-munging of files in some basic format,
f'rexample, you don't particularly need to delve into POSIX esoterica
or some whiz-bang Python bolt-on for frobbing the servos on a lunar
probe while generating novel text from cosmic background radiation; you
certainly can if you want to, but stdlib or the Python equivalent will
get you there just fine.

kalevi@kolttonen.fi (Kalevi Kolttonen) wrote or quoted:
>Okay. I must confess that just seeing the book's size discouraged
>me from buying or reading it. Programming Python, 4th Edition by
>O'Reilly has whopping 1628 pages! This has to be one of the longest
>programming books ever published.

I think the book market offers Python books large and small for
people to choose according to their taste.

You chose to focus on a book that does not please you because
it's too large. Well, you could as well have chosen a tiny
Python book and say it's too small! So your comment is more
a criticism of your own choice of focus than of that book.

>So are you saying that most of the 1628 pages describe libraries
>instead of the core language?

Well, I don't know that specific book, and so I cannot report
its contents. But I don't think its author is named "O'Reilly".

On Fri, 16 Aug 2024 14:57:15 -0000 (UTC), Kalevi Kolttonen wrote:

> So are you saying that most of the 1628 pages describe libraries instead
> of the core language?

I haven’t seen the book, but I would say most definitely. A good book
would not just describe the libraries, but also how to use them
effectively.

There’s a decent amount in the standard Python libraries, but even more so
in the huge number of third-party libraries. This is all part of the
“batteries included” Python philosophy.

On 2024-08-16, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> There’s a decent amount in the standard Python libraries, but even more so
> in the huge number of third-party libraries. This is all part of the
> “batteries included” Python philosophy.

You can have all the batteries-included philosphy in the world, if the
developers don't come to create all those libraries.

Likewise, you can be set against "batteries included", yet be able to do
nothing to stop an army of developers creating a package ecosystem.

Philosophy does dick all, basically.

Many current tools are structured completely contrary to the original
philosophy behind their creation. Things that were supposed to be
simple and small are anything but.

People will crap on your worthless philosophy and do whatever they want.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Fri, 16 Aug 2024 15:02:20 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
>So it is indeed a vague question of what belongs in given programming
>languages.

Indeed. And this gives rise to inconsistency. Why is threading now considered
a core part of C++ but multi process isn't? Perhaps because Windows is hopeless
at the latter in user space but it could just be personal preference within the
C++ steering committee, who knows.

On Fri, 16 Aug 2024, John Ames wrote:

> On Fri, 16 Aug 2024 15:02:20 -0000 (UTC)
> kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>
>> You seem to have a point. The core of C language is also small. I
>> guess they even said in the original K & R book that C is a small
>> language best described by a small book.
>>
>> But in order to do anything with C, you need to know the standard
>> libraries. They have grown bigger and bigger during all these
>> years. One could also well argue that to program on UNIX, you also
>> need to know all the POSIX libraries.
>
> What you *need* is also very much dependent on what you need to *do.*
> If all you're doing is batch-munging of files in some basic format,
> f'rexample, you don't particularly need to delve into POSIX esoterica
> or some whiz-bang Python bolt-on for frobbing the servos on a lunar
> probe while generating novel text from cosmic background radiation; you
> certainly can if you want to, but stdlib or the Python equivalent will
> get you there just fine.
>

I have used bash for those use cases, and one benefit of that is that
script from 10 or 15 years ago still work without any problems at all.

On 2024-08-17 11:01, Muttley@dastardlyhq.com wrote:
> On Fri, 16 Aug 2024 15:02:20 -0000 (UTC)
> kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
>> So it is indeed a vague question of what belongs in given programming
>> languages.
>
> Indeed. And this gives rise to inconsistency. Why is threading now considered
> a core part of C++ but multi process isn't? Perhaps because Windows is hopeless
> at the latter in user space but it could just be personal preference within the
> C++ steering committee, who knows.

Windows inter-process API are far more advanced than what UNIX ever had.
It would be enough to mention famous file locks. These days Linux has
futex + file mapping. So, finally, you can create a system-wide mutex.
Which under Windows is a single API call.
The reason why processes are not included is that they are used to deal
with some OS or design flaw that forces you to spawn some script or
application. Then real-time embedded applications may have no processes
at all.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On Sat, 17 Aug 2024 12:58:31 +0200, Dmitry A. Kazakov wrote:

> Windows inter-process API are far more advanced than what UNIX ever had.
> It would be enough to mention famous file locks.

Except those file locks are more of a liability than an asset. They are
what prevent you from continuing to use a Windows system while it is being
updated, for example.

> The reason why processes are not included is that they are used to deal
> with some OS or design flaw that forces you to spawn some script or
> application.

Or because the *nix tradition of being able to spawn a pipeline of
multiple processes, all cooperating to perform a common task, is difficult
and expensive, or even unreliable, under Windows.

On 2024-08-17 23:51, Lawrence D'Oliveiro wrote:
> On Sat, 17 Aug 2024 12:58:31 +0200, Dmitry A. Kazakov wrote:
>
>> Windows inter-process API are far more advanced than what UNIX ever had.
>> It would be enough to mention famous file locks.
>
> Except those file locks are more of a liability than an asset.

Like so many things in UNIX...

> They are
> what prevent you from continuing to use a Windows system while it is being
> updated, for example.

Windows mutex gets collected when the last process using it dies. UNIX
file lock does not.

>> The reason why processes are not included is that they are used to deal
>> with some OS or design flaw that forces you to spawn some script or
>> application.
>
> Or because the *nix tradition of being able to spawn a pipeline of
> multiple processes, all cooperating to perform a common task, is difficult
> and expensive, or even unreliable, under Windows.

It is as expensive under Windows as it is under UNIX. There is no
problem to produce the same mess as under UNIX. In fact Windows shells
do this just same.

Windows has a pipe object named and anonymous. No problem. Pipes are
rarely used in applications because it is not how distributed systems
(where multiple processes are indeed used) are designed. They usually
require processes be able to run on different nodes.

P.S. It is no wonder that Windows process API are far beyond UNIX.
Historically UNIX started with singe fork() call. There was nothing but
files, no system objects, nothing.
On the other hand, Windows NT was developed by people influenced with
the VMS design. VMS had a very elaborated process communication API. So
Windows inherited much of that, but must importantly the concept of
system resources managed by the OS.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On Sat, 17 Aug 2024 12:58:31 +0200
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> boringly babbled:
>On 2024-08-17 11:01, Muttley@dastardlyhq.com wrote:
>> On Fri, 16 Aug 2024 15:02:20 -0000 (UTC)
>> kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
>>> So it is indeed a vague question of what belongs in given programming
>>> languages.
>>
>> Indeed. And this gives rise to inconsistency. Why is threading now considered
>
>> a core part of C++ but multi process isn't? Perhaps because Windows is
>hopeless
>> at the latter in user space but it could just be personal preference within
>the
>> C++ steering committee, who knows.
>
>Windows inter-process API are far more advanced than what UNIX ever had.

No they're not. The core IPC is less sophisticated than unix but libraries
build upon those shallow foundations.

>It would be enough to mention famous file locks. These days Linux has
>futex + file mapping. So, finally, you can create a system-wide mutex.
>Which under Windows is a single API call.

No sane person uses system wide mutexes as they can cause horrendous
problems.

>The reason why processes are not included is that they are used to deal
>with some OS or design flaw that forces you to spawn some script or
>application. Then real-time embedded applications may have no processes

Clearly you've never written a mission critical server backend. You never
use threads if forking a seperate process can do the same job. If a thread
crashes in a multi threaded server it brings down the entire server. If a
child process crashes, well to bad, but at least the rest of the server
processes are still running.

Also shell pipelining is obviously not something you're familiar with.

On Sun, 18 Aug 2024 10:10:09 +0200
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> boringly babbled:
>On 2024-08-17 23:51, Lawrence D'Oliveiro wrote:
>> Or because the *nix tradition of being able to spawn a pipeline of
>> multiple processes, all cooperating to perform a common task, is difficult
>> and expensive, or even unreliable, under Windows.
>
>It is as expensive under Windows as it is under UNIX. There is no
>problem to produce the same mess as under UNIX. In fact Windows shells
>do this just same.

No they don't - cmd.exe only supports a very limited implemetation of
pipelining. Powershell makes a better attempt at it but still doesn't get
it right.

>Windows has a pipe object named and anonymous. No problem. Pipes are
>rarely used in applications because it is not how distributed systems
>(where multiple processes are indeed used) are designed. They usually

Rubbish. You just made that up. Unix processes that need to talk to their
child processes almost always create a pipe to do so before the fork. Thats
how for example sshd talks to the shell process.

>require processes be able to run on different nodes.

Again - rubbish.

>P.S. It is no wonder that Windows process API are far beyond UNIX.

The windows process API is crippled which is why threading is the main
parallel processing method in Windows and has been since 3.0. If you think
otherwise please give some examples. However I distincly remember trying to
port server to windows only to discover that sockets are some wierd
structure in windows instead of a simple file descriptor meaning it was
impossible to multiplex using poll() or select() on them, you had to have
a seperate thread to manage each connection. What a fucking mess designed
by idiots.

>Historically UNIX started with singe fork() call. There was nothing but
>files, no system objects, nothing.

fork() copies the entire process space. No idea what you mean by "system
objects". Must be some windows thing.

>On the other hand, Windows NT was developed by people influenced with
>the VMS design. VMS had a very elaborated process communication API. So
>Windows inherited much of that, but must importantly the concept of
>system resources managed by the OS.

Windows NT was a slow unreliable dog. Even microsoft didn't use it for their
heavy duty backend servers, they used BSD and AS400s instead.

In article <v9sa91$2afht$1@dont-email.me>,
Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>On 2024-08-17 23:51, Lawrence D'Oliveiro wrote:
>> On Sat, 17 Aug 2024 12:58:31 +0200, Dmitry A. Kazakov wrote:
>>
>>> Windows inter-process API are far more advanced than what UNIX ever had.
>>> It would be enough to mention famous file locks.
>>
>> Except those file locks are more of a liability than an asset.
>
>Like so many things in UNIX...

Ah, funny!

Yup - just what we need: Another Unix vs. Windows dick waving contest!!!

So productive use of Usenet bandwidth.

--
If there is anything more pathetic than Dr. Donald Trump, MD, giving out medical
advice, it is the pathetic followers of Dr. Trump trying to implement said advice.

On Sun, 18 Aug 2024 08:55:49 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) boringly babbled:
>In article <v9sa91$2afht$1@dont-email.me>,
>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>On 2024-08-17 23:51, Lawrence D'Oliveiro wrote:
>>> On Sat, 17 Aug 2024 12:58:31 +0200, Dmitry A. Kazakov wrote:
>>>
>>>> Windows inter-process API are far more advanced than what UNIX ever had.
>>>> It would be enough to mention famous file locks.
>>>
>>> Except those file locks are more of a liability than an asset.
>>
>>Like so many things in UNIX...
>
>Ah, funny!
>
>Yup - just what we need: Another Unix vs. Windows dick waving contest!!!
>
>So productive use of Usenet bandwidth.

Yes, no doubt the providers will be struggling under the kilobytes of data
being used.

Feel free to post something else of interest.

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.

> If you think
> otherwise please give some examples. However I distincly remember trying to
> port server to windows only to discover that sockets are some wierd
> structure in windows instead of a simple file descriptor meaning it was
> impossible to multiplex using poll() or select() on them, you had to have
> a seperate thread to manage each connection. What a fucking mess designed
> by idiots.

There is no problem using socket select with Windows. Here is an
implementation of a server doing that:

http://www.dmitry-kazakov.de/ada/components.htm#17.1

You can check the Windows implementation of to learn how it is done with
Windows sockets.

>> Historically UNIX started with singe fork() call. There was nothing but
>> files, no system objects, nothing.
>
> fork() copies the entire process space. No idea what you mean by "system
> objects". Must be some windows thing.

Objects managed by the OS.

>> On the other hand, Windows NT was developed by people influenced with
>> the VMS design. VMS had a very elaborated process communication API. So
>> Windows inherited much of that, but must importantly the concept of
>> system resources managed by the OS.
>
> Windows NT was a slow unreliable dog.

It is not slow. Actually you can get same or better performance under
Windows as under Linux. The problem is the default settings of the
scheduling time interval. It is 10ms by default. Set it to 1ms and you
will see the difference. Unfortunately 1ms is the hard limit. If you
want it better, OK, there is VxWorks where you can go under 1ms.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 16/08/2024 17:02, Kalevi Kolttonen wrote:
> In comp.unix.programmer Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>> On 2024-08-15, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Thu, 15 Aug 2024 19:48:36 -0000 (UTC), Kalevi Kolttonen wrote:
>>>
>>>> The last I checked, the O'Reilly Python book is just absolutely
>>>> *MASSIVE*. The language has a huge number of features now ...
>>>
>>> No, it hasn’t. The core language reference spec is only a small fraction
>>> of, say, the Java language spec.
>>>
>>> It’s just that you can do so many things with Python. And that is down to
>>> the huge variety of off-the-shelf addon libraries that build on that core
>>> language spec. It has to be a strong, very solidly founded core in order
>>> to be such a versatile basis for these addons, and it is.
>>
>> That's idiotic; you're saying that the standard library packages of
>> Python are not part of Python, and do not contribute to its size.
>
> You seem to have a point. The core of C language is also small. I
> guess they even said in the original K & R book that C is a small
> language best described by a small book.
>
> But in order to do anything with C, you need to know the standard
> libraries. They have grown bigger and bigger during all these
> years. One could also well argue that to program on UNIX, you also
> need to know all the POSIX libraries.
>

Absolute nonsense.

In order to use a programming language for a given task, you need to
know the basics of the language and libraries appropriate for the task.
You most certainly do not need to know all about the language, or all
about all the libraries provided as standard for the language or the
host OS.

You usually need to know /some/ of a language's standard libraries, but
far from all of it. And unless you are writing a compiler, you don't
need to know all of the core language for most languages. And that
applies equally to languages with relatively small cores and standard
libraries, like C.

Without looking it up, what does the C standard library "fegetmode"
function do? What does "static" mean inside square brackets in a C
function prototype? What are the differences in the rules for integer
constants in C90 and C99? What functions are in the POSIX header
<libgen.h> ?

Do you think people "can't do anything with C" if they can't answer
those questions?

> So it is indeed a vague question of what belongs in given programming
> languages.
>

That is true, but not for the reason you gave.

On 17/08/2024 11:01, Muttley@dastardlyhq.com wrote:
> On Fri, 16 Aug 2024 15:02:20 -0000 (UTC)
> kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
>> So it is indeed a vague question of what belongs in given programming
>> languages.
>
> Indeed. And this gives rise to inconsistency. Why is threading now considered
> a core part of C++ but multi process isn't? Perhaps because Windows is hopeless
> at the latter in user space but it could just be personal preference within the
> C++ steering committee, who knows.
>

No, it is because of what the term "program" usually means, along with
the terms "process" and "thread" (at the OS level). With C++, you write
"programs", and each process is a running program. Like most languages,
C++ does not cover what happens outside the program - that's part of the
OS specification, or specifications for other programs or other parts of
the complete system. But threads are /within/ the program, and thus
covered (to at least some extent) by the language used to write the program.

It has nothing to do with OS's and their strengths or weaknesses (real
or perceived).

On Sun, 18 Aug 2024 16:59:02 +0200
David Brown <david.brown@hesbynett.no> boringly babbled:
>On 17/08/2024 11:01, Muttley@dastardlyhq.com wrote:
>> On Fri, 16 Aug 2024 15:02:20 -0000 (UTC)
>> kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
>>> So it is indeed a vague question of what belongs in given programming
>>> languages.
>>
>> Indeed. And this gives rise to inconsistency. Why is threading now considered
>
>> a core part of C++ but multi process isn't? Perhaps because Windows is
>hopeless
>> at the latter in user space but it could just be personal preference within
>the
>> C++ steering committee, who knows.
>>
>
>No, it is because of what the term "program" usually means, along with
>the terms "process" and "thread" (at the OS level). With C++, you write
>"programs", and each process is a running program. Like most languages,
>C++ does not cover what happens outside the program - that's part of the
>OS specification, or specifications for other programs or other parts of
>the complete system. But threads are /within/ the program, and thus
>covered (to at least some extent) by the language used to write the program.

Sorry, thats just word salad. The program is the code, how many copies of it
are running is irrelevant.

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 so while the
processes are only reading its no different to threading. I doubt windows
implements CoW since - in user space at least - it can't do fork and you
wouldn't need it for executing a brand new process from scratch.

Also shared memory is pretty cheap too.

>> otherwise please give some examples. However I distincly remember trying to
>> port server to windows only to discover that sockets are some wierd
>> structure in windows instead of a simple file descriptor meaning it was
>> impossible to multiplex using poll() or select() on them, you had to have
>> a seperate thread to manage each connection. What a fucking mess designed
>> by idiots.
>
>There is no problem using socket select with Windows. Here is an
>implementation of a server doing that:
>
> http://www.dmitry-kazakov.de/ada/components.htm#17.1
>
>You can check the Windows implementation of to learn how it is done with
>Windows sockets.

No idea what the pages of all that crap is.

Windows sockets are not integers , they can't be multiplexed with file
descriptors, pipes etc in a single call.

>> fork() copies the entire process space. No idea what you mean by "system
>> objects". Must be some windows thing.
>
>Objects managed by the OS.

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

>> Windows NT was a slow unreliable dog.
>
>It is not slow. Actually you can get same or better performance under
>Windows as under Linux. The problem is the default settings of the

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

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.

> 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.

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...

> 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!

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

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

>>> fork() copies the entire process space. No idea what you mean by "system
>>> objects". Must be some windows thing.
>>
>> Objects managed by the OS.
>
> 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.

> 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.

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.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 18/08/2024 15:55, David Brown wrote:

....

> What does "static" mean inside square brackets in a C
> function prototype?

I know there's a better newsgroup for it but, since you brought it up
and it does also fit here, I should say that I had no idea that a C
program could have square brackets in a function prototype and I cannot
think of ever seeing such a thing.

I presume you do mean C and not some sort of compiler extension.

As for static, IIRC labelling as "static" any external name (i.e. one
not in a function) would make it private to the CU and not visible
outside but that is just a guess.

Or perhaps you meant a static formal parameter. Again, not something
I've ever come across and would be curious as to what it meant.

Would you care to say more about what you had in mind?

--
James Harris