What is on topic here

[Seebs]

Could be. What I was thinking is that Windows probably provides
a set of library routines that's similar enough to the POSIX
threads routines that mapping from one to the other would not be
especially difficult, and that the same would probably be true
for most other mainstream platforms.

I'm not sure of this.

Consider process management APIs; you'd think they'd be similar, but they're
sufficiently dissimilar that trying to port a lot of Unix code to Windows
is a horrible nightmare which imposes HUGE costs.

Yeah, okay, maybe I'm being too optimistic to think that multithreading
will ever be no more difficult .... or even "not much more difficult".

I think so. Not to say it hasn't gotten a lot better than it was ten or
fifteen years ago.

But I think this would *not* be an implementation of the semaphore ADT
as defined in computer science. ?

Well, no, it wouldn't. But it would fit in nicely next to "morse.h".

-s

 

[blmblm]

I'm not sure of this.

Consider process management APIs; you'd think they'd be similar, but they're
sufficiently dissimilar that trying to port a lot of Unix code to Windows
is a horrible nightmare which imposes HUGE costs.

Can you easily say more about this? I'm reasonably familiar with
how one creates new processes in UNIX (fork(), often followed
by exec*()) but have only the vaguest idea of how it's done in
Windows (some library function that sort of combines the two).
I can imagine that this would make porting not totally trivial,
but "horrible nightmare" -- how so?

[ snip ]

 

[Seebs]

Can you easily say more about this?

A little, although it rapidly becomes unportable.

The following is fairly off-topic, except insofar as it highlights that a
similar API may not be an interchangeable one.

I'm reasonably familiar with
how one creates new processes in UNIX (fork(), often followed
by exec*()) but have only the vaguest idea of how it's done in
Windows (some library function that sort of combines the two).
I can imagine that this would make porting not totally trivial,
but "horrible nightmare" -- how so?

Many UNIX programs rely VERY heavily on doing a fork() *without*
an exec().

Consider a shell. In a standard UNIX shell, many commands are "built-in";
they are handled by the shell rather than by an external program. Imagine
that you write:

echo foo | grep bar

(obviously, useless, but there is a category of things like this that
people sometimes do).

It is quite possible that the "echo" command will have to be run in what
is called a "subshell" -- a separate process, so that it can run at the same
time as the other command. In UNIX, the shell does this by calling fork()
and then simply executing code. It already has all the environment set up
to be a working, complete, shell, so it doesn't have to spend any time doing
that. Under Windows, to simulate this, you have to figure out some way to
dump enough of your state somewhere that you can recreate it, spawn a new
program, and then restore all that state.

Since typical shell programs create hundreds of subshells, this makes for
an order of magnitude or worse performance penalty for running shell programs
on Windows, because there's no analogue to fork().

-s

 

[blmblm]

A little, although it rapidly becomes unportable.

The following is fairly off-topic, except insofar as it highlights that a
similar API may not be an interchangeable one.

Agreed that it's off-topic, but this whole subdiscussion has been
off-topic here. But maybe after this post we'll be done ....

[ snip ]

Many UNIX programs rely VERY heavily on doing a fork() *without*
an exec().

Consider a shell. In a standard UNIX shell, many commands are "built-in";
they are handled by the shell rather than by an external program. Imagine
that you write:

echo foo | grep bar

(obviously, useless, but there is a category of things like this that
people sometimes do).

It is quite possible that the "echo" command will have to be run in what
is called a "subshell" -- a separate process, so that it can run at the same
time as the other command. In UNIX, the shell does this by calling fork()
and then simply executing code. It already has all the environment set up
to be a working, complete, shell, so it doesn't have to spend any time doing
that. Under Windows, to simulate this, you have to figure out some way to
dump enough of your state somewhere that you can recreate it, spawn a new
program, and then restore all that state.

Since typical shell programs create hundreds of subshells, this makes for
an order of magnitude or worse performance penalty for running shell programs
on Windows, because there's no analogue to fork().

Ah. Excellent example (though maybe I only think that because of
how many hours of entertainment I've gotten out of writing a very
simple shell and then trying to add some of the functionality of
real shells ).

The flip side of this is that fork() does seem to have some
potential for inefficiency, since conceptually it involves
duplicating an address space, so it might be nice if UNIX had
something analogous to what Windows seems to provide ....

I'd better stop there, though, before I start replaying a
discussion I've had at least once in the past year or so, in
Usenet group(s) in which it was actually on-topic.