[9fans] Fork: useless and painful?

[9fans] Fork: useless and painful?

[ron minnich]

I'm hearing the claim that fork is "useless and painful" (from an IBM K42
guy).

Maybe it's just me, but I've always liked fork.

Am I nuts?

ron

Re: [9fans] Fork: useless and painful?

[Scott Schwartz]

Ron says:
| I'm hearing the claim that fork is "useless and painful" (from an IBM K42
| guy).
|
| Maybe it's just me, but I've always liked fork.
|
| Am I nuts?

Not at all.  But all the published programs that people see use pthreads,
which is an anti-unix design.  If you want to change people's minds,
you have to show them programs that use rfork effectively.  (Linux has
cleverly engineered clone so that it can't be used directly, which feeds
the idea that pthreads are the right thing.)

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> ... But all the published programs that people see use pthreads,
> which is an anti-unix design.

pthreads?  yeah, i wrote some of that once -- ghastly.  all those
extra characters to type and if you get it wrong, well your code
breaks.

i think rob said once that:

    concurrent [thread] programming is beyond the capabilities of
    most programmers.

i tend to agree.  look what they did to ls(1) on lunix ...

Re: [9fans] Fork: useless and painful?

[Dan Cross]

> i tend to agree.  look what they did to ls(1) on lunix ...

Okay, this *raises* the question (Hi, Matt!): What *did* they do to
ls on lunix?  The only thing I've noticed about it is that they've
changed around the default sorting order, and I can't find a way to
get the traditional behavior.  Actually, it's really irritating.

	- Dan C.

Re: [9fans] Fork: useless and painful?

[Derek Fawcus]

On Wed, Jul 09, 2003 at 03:45:29PM -0400, Dan Cross wrote:
> The only thing I've noticed about it is that they've
> changed around the default sorting order, and I can't find a way to
> get the traditional behavior.  Actually, it's really irritating.

I find it really bloody annoying,  however 'LC_ALL=C ls' put's things
back the way they should be...

Re: [9fans] Fork: useless and painful?

[andrey mirtchovski]

On Wed, 9 Jul 2003, Derek Fawcus wrote:

> I find it really bloody annoying,  however 'LC_ALL=C ls' put's things
> back the way they should be...
>

and "export LD_DEBUG=all; ls" will show you things you never wanted to know

:)

Re: [9fans] Fork: useless and painful?

[Derek Fawcus]

On Wed, Jul 09, 2003 at 02:09:17PM -0600, andrey mirtchovski wrote:
> On Wed, 9 Jul 2003, Derek Fawcus wrote:
>
> > I find it really bloody annoying,  however 'LC_ALL=C ls' put's things
> > back the way they should be...
> >
>
> and "export LD_DEBUG=all; ls" will show you things you never wanted to know

and those are the reasons I've replaced the my ls with the one from embutils

Re: [9fans] Fork: useless and painful?

[Vincent van Gelderen]

On Wednesday 09 July 2003 22:09, andrey mirtchovski wrote:

> and "export LD_DEBUG=all; ls" will show you things you never wanted to know
>

Incroyable! On my particular machine:

linux:~> (export LD_DEBUG=all; ls /dev/zero) 2>&1 | wc
   1093    6380   74269

Regards,
Vincent van Gelderen

Re: [9fans] Fork: useless and painful?

[Sam]

> Incroyable! On my particular machine:
>
> linux:~> (export LD_DEBUG=all; ls /dev/zero) 2>&1 | wc
>    1093    6380   74269

$ LD_DEBUG=all ls /dev/zero 2>&1 | wc
   1388    8913   94822
$

Bugger.  Your ls must be more optimised. ;)

Sam

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> Incroyable!

quelle putain de connerie!!

Re: [9fans] Fork: useless and painful?

[andrey mirtchovski]

On Wed, 9 Jul 2003, Sam wrote:

>
> Bugger.  Your ls must be more optimised. ;)
>

I bet you're running a later distribution -- with linux those things
just grow uncontrollably with time.

expect 'ld' in the kernel come 2.6.0...

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> I bet you're running a later distribution -- with linux those things
> just grow uncontrollably with time.

debian's apt-get:  it's not apt, but it does get [on your nerves]

Re: [9fans] Fork: useless and painful?

[ron minnich]

On Wed, 9 Jul 2003, Vincent van Gelderen wrote:

> On Wednesday 09 July 2003 22:09, andrey mirtchovski wrote:
>
> > and "export LD_DEBUG=all; ls" will show you things you never wanted to know
> >
>
> Incroyable! On my particular machine:
>
> linux:~> (export LD_DEBUG=all; ls /dev/zero) 2>&1 | wc
>    1093    6380   74269

As I said when I first posted this number a year ago, back when it only
fixed up 300-odd symbols:
"masataka ohta, where are you now, you were right all along"

ron

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> fixed up 300-odd symbols:

symbols?  give me an LA-120 printed VAX stack backtrace and adb and i'm happy.

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

>  Actually, it's really irritating.

well there is that.  and the ls | mc default and the colours based on file type
...

explain to my why:

    ls

and:

    ls | cat

give diffferent visual [human readable] outputs?

oh, yeah, don't forget the mmap() implementation of cat -- try that on a pipe
...

now, don't get me all contrary ...

Re: [9fans] Fork: useless and painful?

[Dan Cross]

"boyd, rounin" <boyd@insultant.net> writes:
>
> >  Actually, it's really irritating.
>
> well there is that.  and the ls | mc default and the colours based on file
> type ...

Oh, I turned that junk off.  Ls is aliased to ls -1A and lc is aliased to
ls | mc, as it should be (using my Unix version of mc).

> oh, yeah, don't forget the mmap() implementation of cat -- try that on a pipe
> ...

Yeah, that is dumb.

> now, don't get me all contrary ...

:-)

I still find Lunix horrible, but at least it's tolerable for the most
part at this point.

	- Dan C.

Re: [9fans] Fork: useless and painful?

[Dan Cross]

Derek Fawcus <dfawcus@cisco.com> writes:
>
> On Wed, Jul 09, 2003 at 03:45:29PM -0400, Dan Cross wrote:
> > The only thing I've noticed about it is that they've
> > changed around the default sorting order, and I can't find a way to
> > get the traditional behavior.  Actually, it's really irritating.
>
> I find it really bloody annoying,  however 'LC_ALL=C ls' put's things
> back the way they should be...

Ahh....  Thanks to you and Vic for telling me this.  I feel much more
at home now.

	- Dan C.

Re: [9fans] Fork: useless and painful?

[Mike Haertel]

>> The only thing I've noticed about it is that they've
>> changed around the default sorting order, and I can't find a way to
>> get the traditional behavior.  Actually, it's really irritating.
>
>I find it really bloody annoying,  however 'LC_ALL=C ls' put's things
>back the way they should be...

I've seen this on Solaris too, so it's hardly a Linux thing.  In
fact, I saw it on Solaris before I ever saw it on Linux.  So by the
time it started popping up on Linux, I knew what to do.  I am pleased
to report that the disease has not yet spread to FreeBSD, at least.

I think the root of the problem is that in Unix-family operating
systems (including Plan 9) the shell and utilities have tried to
serve two different masters, which is always hard.

On one hand, they form a programming language, for which well-defined
behavior is a paramount consideration.  But on the other hand, they
are a user interface.  And people like their interfaces to conform
to their prejudices and comfort zones, rather than having to conform
their behavior to fit a logically minimal interface.

This tension has been in Unix for a long time.  An early example
was the multi-column support in Berkeley "ls" which changed its
behavior depending on whether it thought it was talking to a human
or not.  The recent disease of making all kinds of utilities default
to using locale-specific sorting rather than native machine sorting
is just the latest in a long line of plagues.

The recent Unix/Posix changes are especially ironic and ill-conceived
because they are attempting to change command-line interfaces to
be more "user friendly" at a point in history when all the users
who need "friendliness" are pretty much exclusively using graphical
interfaces anyway.

On the other hand, it would be fair to say that a lot of the power
of Unix as a programming environment comes from developing familiarity,
through routine interactive use, with tools that one can subsequently
incorporate into programs.

So if you can get people to use things interactively you may be
able to turn them into programmers, and that may justify trying to
engineer the command line environment in fuzzy human friendly ways.
But while having logically unnecessary but supposedly human-friendly
features may be reasonable, it's surely NOT an goal that justifies
any design no matter how awful.

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> I think the root of the problem is that in Unix-family operating
> systems (including Plan 9) the shell and utilities have tried to
> serve two different masters, which is always hard.

internationalisation is hard.  forget about french; all those diacritical
marks are just the same as ' in english -- used to replace 'missing'
characters:

    hôpital = hospital 'cos the ô = os

whereas in swedish they have 3 extra real vowels.  sure they have
diacritical marks but they are _real characters_ with a collating
sequence and a nasty set of pronounciation rules.

take iso latin 1:  sure, you have all the chars but it depends on
_where_ you are as:

   Fredrik (listen to me) Juhlin  <laz@strakt.com>

pointed out to me and i had to rethink my internationalisation thoughts.

and, yeah, he was right.

Re: [9fans] Fork: useless and painful?

[Geoff Collyer]

The latest bit of whacked behaviour can be seen on RedHat 9, where if
you don't set LANG in your .profile, you get LANG=en_US.UTF-8, which
does this:

: secgw.sec; ls -lA
total 716
-r--r--r--    1 geoff    geoff       92160 2003-06-22 21:36 9wm-1.2.tar
lrwxrwxrwx    1 geoff    geoff          11 2003-06-22 20:03 .acrorc -> lib/.acrorc
lrwxrwxrwx    1 geoff    geoff           9 2003-06-22 20:18 .bash_history -> /dev/null
drwxr-xr-x    4 geoff    geoff        4096 2003-06-22 16:13 bin
-rw-------    1 geoff    geoff          16 2003-06-26 23:09 .esd_auth
lrwxrwxrwx    1 geoff    geoff          15 2003-06-22 20:03 .find.codes -> lib/.find.codes
-rw-rw-r--    1 geoff    geoff       24030 2003-07-01 02:13 .fonts.cache-1
-rw-rw-r--    1 geoff    geoff       99551 2003-06-25 05:07 FOOFILE
-rw-rw-r--    1 geoff    geoff      315392 2003-06-25 05:49 FOOFILE2
-rw-rw-r--    1 geoff    geoff         126 2003-06-25 05:56 FOOFILE3

different unhelpful sort order, ugly all-numeric dashed dates and ghod
only knows what other stupidity.  Luckily, adding LANG=C to your
.profile defeats this.

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

i quick test for an idiot european is:

    env | egrep 'LANG|LC_'

if LANG != C or LC_ALL != C you have a prize idiot because they
are trusting the interesting instationaliZation (sic) done by americans.

doing that stuff is hard and lunix got it all wrong.

given that i'm feeling 'contrary':  why doesn't the installation process
ask you what sort of keyboard you have?

i can type qwerty, azerty and swedish qwerty but it really is a pain to
have to type qwerty on an azerty keyboard to get to the point where
i can type chars to build the kernel etc that i want.

the 'kbmap' stuff is trivial to install if you can type the chars on the
keyboard.
trying to install it when you don't have a qwerty keyboard, well it's less than
pleasant.

it wouldn't be hard to add and it would make the system more open to
europeans.

i'd do it, mais j'ai d'autres chats à foutter ...

and going back to being 'contrary' your setup had better look pretty much
like what they have at the labs.  this is a semi-criticism, because it's
1127-centric but (thank ...) it's not the 'army of programmers' ...

Re: OT lunix rants (Was: [9fans] Fork: useless and painful?)

[andrey mirtchovski]

On Thu, 10 Jul 2003, boyd, rounin wrote:

> i quick test for an idiot european is:
>
>     env | egrep 'LANG|LC_'
>

since we're ranting, anyways:

to read utf-8 in lunix I need to set:

	LANG=en_US.UTF-8 (no, not bg_BG.UTF-8, because then lpr decides to print
	in A4 only, and there's no printer here that'd do it, unless I have a
	dead chicken to wave at it. we have mad cow in calgary, not dead
	chickens)

	-u8 to xterm (no chance of using other terminals -- 9term works with utf,
	but linux doesn't work with 9term)

	-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1  - my
	personal favourite. sometimes I need to switch fonts because this one
	doesn't have a full set of glyphs..

	-iconv handy -- for all the stupid bulgarians that still use KOI8-r,
	Windows-cp1251, KOI8-u, Codepage-866, ISO-8859-5 and god knows what
	else


to write utf-8 in lunix I need to set (in X11):

    -Option      "XkbLayout" "bg"    #Option "XkbVariant"    "" -- to
	tell it that it's a bulgarian sitting behind the keyboard (to scare
	it perhaps and force X into submission?)

    -Option      "XkbVariant" "phonetic_enhanced" -- 'phonetic_bds' is a
	local to eastern european countries layout for typewriters, where all the
	vowels are on one side of the keyboard, it's there in case we ought to
	torture somebody and are out of other options

    -Option      "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll" -- try
	to decipher that on your own.

There is no conceivable set of documentation that explains how to do it in
one go -- one has to be 'enlightened' by somebody who already knows this
stuff.

Re: OT lunix rants (Was: [9fans] Fork: useless and painful?)

[boyd, rounin]

> There is no conceivable set of documentation that explains how to do it in
> one go -- one has to be 'enlightened' by somebody who already knows this
> stuff.

yup, welcome to lunix ...

Re: [9fans] Fork: useless and painful?

[Mike Haertel]

>-rw-rw-r--    1 geoff    geoff       24030 2003-07-01 02:13 .fonts.cache-1
>-rw-rw-r--    1 geoff    geoff       99551 2003-06-25 05:07 FOOFILE
>
>different unhelpful sort order, ugly all-numeric dashed dates and ghod
>only knows what other stupidity.  Luckily, adding LANG=C to your
>.profile defeats this.

While I agree the sort ordering on names is terrible, I'd argue the
"ugly all-numeric dashed dates" are actually more desirable than the
traditional Unix format, because they are more sortable.

With traditional Unix date strings you get into all sorts of ugly
contortions if you want to run them through sort(1).  System V added
a -M option to sort to do grok month names, but it is still unpleasant.

Re: [9fans] Fork: useless and painful?

[Geoff Collyer]

Your point is taken.  I wouldn't object as much to an option to ls
(though ls already has too many options) to print times in the ugly
all-numeric format or just as seconds since the epoch, but to change
the default output format at this late date to the ugly format, with
no obvious way to disable it (I can't see how in a quick reading of
Linux's ls(1)), seems wrong.

To really pick nits, why should setting LANG=en_US.UTF-8 bugger the
sort order and change to all-numeric uglies?  I'm an English-speaker
in the US who prefers UTF-8, and I don't want any of this rubbish.
Actually the all-numeric uglies I sort of understand; I'd never seen
such aversion to four-digit years and month names, despite the
ambiguity of all-numeric dates internationally, until I moved to the
US.  But if I wanted my ls output in `sort -df' order, I'd pipe it
through `sort -df +8'.  These changes are just somebody's favourite
dumb ideas glommed onto a convenient locale.

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> To really pick nits, why should setting LANG=en_US.UTF-8 bugger the
> sort order and change to all-numeric uglies?  I'm an English-speaker
> in the US who prefers UTF-8, and I don't want any of this rubbish.

yup i bitch to google about such, err, assumpions.

so i'm in oz, so i'm australian.

i'm in france so i'm french.

i'm in sweden so i'm swedish.

NO, just shut up.  i want http://www.google.com in english and they then
tell me to use random URL whatever and it's in english, except the banner
says:

    Google
            Français

i know what i want;  assumption being the mother of all clusterfucks.

call me contrary, but i know what i want.

it's all mike burrows' fault anyway ...

Re: [9fans] Fork: useless and painful?

[Derek Fawcus]

On Thu, Jul 10, 2003 at 09:22:39AM +0200, boyd, rounin wrote:
> > To really pick nits, why should setting LANG=en_US.UTF-8 bugger the
> > sort order and change to all-numeric uglies?  I'm an English-speaker
> > in the US who prefers UTF-8, and I don't want any of this rubbish.
>
> yup i bitch to google about such, err, assumpions.
>
> so i'm in oz, so i'm australian.
>
> i'm in france so i'm french.
>
> i'm in sweden so i'm swedish.

Oh - I can beat that.   I'm in the UK,  but if I use google.com I get it
in Dutch.  That's would appear to be 'cause our network connectivity pops
outside of the company in Amsterdam...

DF

Re: [9fans] Fork: useless and painful?

[Alexis S. L. Carvalho]

Thus spake Geoff Collyer:
> To really pick nits, why should setting LANG=en_US.UTF-8 bugger the
> sort order and change to all-numeric uglies?  I'm an English-speaker
> in the US who prefers UTF-8, and I don't want any of this rubbish.

(Please don't shoot me for knowing this...)

There are quite a few locale categories - LC_CTYPE specifies the
encoding used, LC_COLLATE the sorting order and so on.  You can see
their current value using the command locale.

LANG specifies the default value for all categories;  you can override
one particular category with LC_CTYPE, LC_COLLATE etc.

LC_ALL overrides both LC_* and LANG.

In a nutshell: use LANG=C and LC_CTYPE=en_US.UTF-8 and you should be
happier.

Alexis

Re: [9fans] Fork: useless and painful?

[Dan Cross]

> I'm hearing the claim that fork is "useless and painful" (from an IBM K42
> guy).
>
> Maybe it's just me, but I've always liked fork.

> Am I nuts?

Well, for what?  I find fork useful for all sorts of things  For
running another program, I never did quite figure out why there wasn't
a `spawn' library function that did the dance for you; I could see
fork() looking like an unnecessary extra step if that's all you ever
saw it do, but then I'd just point to pipelines of commands and the
simplicity of `backgrounding' a process as a counter example.

And, of course, rfork() is pretty cool, as Scott pointed out.

	- Dan C.

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> Maybe it's just me, but I've always liked fork.

yeah, i kinda like it too.

on the one had we have fork() -- zero arguments.

then, we have on NT CreateProcess() which takes 10 arguments and two of
those are structs (iirc).  now the only _feature_ here is that all the args and
and values in the structs can be either 0 or NULL;  write once, copy and paste
everywhere.

maybe it's just me.  if 10 was 0?

Re: [9fans] Fork: useless and painful?

[rog]

> I'm hearing the claim that fork is "useless and painful" (from an IBM K42
> guy).
>
> Maybe it's just me, but I've always liked fork.

fork's kinda nice, but can be confusing.
plan9 has really moved away from fork for multithreaded programs
towards the "spawn" style proccreate.  (rfork for other resource
attributes is quite different, i think)

a day or so ago, i had occasion to write the following code:

	int
	mpipe(void)
	{
		char buf[BUFSIZE];
		int n, p[2];

		pipe(p);
		if(fork() == 0){
			if(fork() == 0){
				close(p[1]);
				return p[0];
			}
			close(p[0]);
			while((n = read(0, buf, sizeof(buf))) > 0)
				write(p[1], buf, n);
			exits(nil);
		}
		close(p[0]);
		while((n = read(p[1], buf, sizeof(buf))) > 0)
			write(1, buf, n);
		exits(nil);
	}

there's nothing particularly complicated going on and i don't *think*
the implementation is particularly obtuse, but i don't find reading
that code straightforward.

here's a different structure to the same end:

	int
	mpipe(void)
	{
		int p[2];
		pipe(p);
		spawn copy(0, p[1]);
		spawn copy(p[1], 1);
		return p[0];
	}

	void
	copy(int fd0, int fd1)
	{
		char buf[BUFSIZE];
		int n;
		while((n = read(fd0, buf, sizeof(buf))) > 0)
			write(fd1, buf, n);
	}

ok, i cheated, assuming that C has been given a "spawn" statement
similar to Limbo's.  nonetheless, i think the structure itself is
clearer, and the meaning of the code more transparent - no possibility
of accidentally duplicating the *caller* of mpipe...

given that forking a process in plan 9, unlike unix, is not synonymous
with forking its file descriptors, surely the only real reason to
prefer it is that the call fits more nicely into the C syntax; one
doesn't have to bypass typechecking in order to pass arguments to a
new process.

how often does anyone do anything with fork that could not be done at
least as easily with spawn?

Re: [9fans] Fork: useless and painful?

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

That's why we have libthread with its threadcreate/proccreate/procexec.
I've been moving stuff over to windows and just kept the libthread
interface.

It's amazing how awkward win32 makes all of the same.  Every
process control call turns into a handful of calls, each with
a dozen params.

[-- Attachment #2: Type: message/rfc822, Size: 3652 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Fork: useless and painful?
Date: Thu, 10 Jul 2003 15:59:34 +0100
Message-ID: <212c59d55eb25badcbc00c9fe4121065@vitanuova.com>

> I'm hearing the claim that fork is "useless and painful" (from an IBM K42
> guy).
>
> Maybe it's just me, but I've always liked fork.

fork's kinda nice, but can be confusing.
plan9 has really moved away from fork for multithreaded programs
towards the "spawn" style proccreate.  (rfork for other resource
attributes is quite different, i think)

a day or so ago, i had occasion to write the following code:

	int
	mpipe(void)
	{
		char buf[BUFSIZE];
		int n, p[2];

		pipe(p);
		if(fork() == 0){
			if(fork() == 0){
				close(p[1]);
				return p[0];
			}
			close(p[0]);
			while((n = read(0, buf, sizeof(buf))) > 0)
				write(p[1], buf, n);
			exits(nil);
		}
		close(p[0]);
		while((n = read(p[1], buf, sizeof(buf))) > 0)
			write(1, buf, n);
		exits(nil);
	}

there's nothing particularly complicated going on and i don't *think*
the implementation is particularly obtuse, but i don't find reading
that code straightforward.

here's a different structure to the same end:

	int
	mpipe(void)
	{
		int p[2];
		pipe(p);
		spawn copy(0, p[1]);
		spawn copy(p[1], 1);
		return p[0];
	}

	void
	copy(int fd0, int fd1)
	{
		char buf[BUFSIZE];
		int n;
		while((n = read(fd0, buf, sizeof(buf))) > 0)
			write(fd1, buf, n);
	}

ok, i cheated, assuming that C has been given a "spawn" statement
similar to Limbo's.  nonetheless, i think the structure itself is
clearer, and the meaning of the code more transparent - no possibility
of accidentally duplicating the *caller* of mpipe...

given that forking a process in plan 9, unlike unix, is not synonymous
with forking its file descriptors, surely the only real reason to
prefer it is that the call fits more nicely into the C syntax; one
doesn't have to bypass typechecking in order to pass arguments to a
new process.

how often does anyone do anything with fork that could not be done at
least as easily with spawn?

Re: [9fans] Fork: useless and painful?

[Stephen Wynne]

David Presotto wrote:

> It's amazing how awkward win32 makes all of the same.  Every
> process control call turns into a handful of calls, each with
> a dozen params.

Yes, I'm noticing! On a related note, since I've been looking at
how to solve the probelm with console hacking:

Lately I've been wanting pseudo terminals because my rshd.exe
gives me stdout in line buffered mode, causing un-line-terminated
program prompts to only be output after the program exits (if
at all). I haven't tried to run anything that reads or writes directly
to the console yet, but I trust those kinds of programs are common
enough.

Where is the joy in computing? Win32 is making me wonder.

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> Where is the joy in computing? Win32 is making me wonder.

been there, done that.  a repeat of SysVile (sic) R3:

    you could select on a socket or poll on a stream,
    but they would not interoperate

on NT you need to call WaitForMultipleObjects() iirc and
that doesn't work on WinShlock (sic) sockets etc, so you
have to use a threaded implementation.

for extra points, if the NT CreateSocket() call finds that you
are _not_ WinShlock (sic) the call fails and returns -6 iirc.

Re: [9fans] Fork: useless and painful?

[Stephen Wynne]

And I just got a suggestion to use named pipes, presumably because
they have a richer set of buffering options.

I don't think named pipes help one with the situation where a
DOS program does direct console I/O. I think "net use" does
that when it prompts you for a password; you get the idea,
in any case. My line buffering app is cacls.exe (don't laugh).

I don't think I am going to work on this more right now, but
if I were, I would try to replace the standard I/O via plain pipes
connected to winsock sockets with standard I/O through dedicated
but hidden consoles for each connection. I think it's possible.

As an aside, UWIN's rshd is just as bad, and Cygwin's is worse.
I'm guessing Microsoft's telnetd is fairly brain dead in this
respect, as well.

boyd, rounin wrote:
>>Where is the joy in computing? Win32 is making me wonder.
>
>
> been there, done that.  a repeat of SysVile (sic) R3:
>
>     you could select on a socket or poll on a stream,
>     but they would not interoperate
>
> on NT you need to call WaitForMultipleObjects() iirc and
> that doesn't work on WinShlock (sic) sockets etc, so you
> have to use a threaded implementation.
>
> for extra points, if the NT CreateSocket() call finds that you
> are _not_ WinShlock (sic) the call fails and returns -6 iirc.
>
>

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> As an aside, UWIN's rshd is just as bad, and Cygwin's is worse.
> I'm guessing Microsoft's telnetd is fairly brain dead in this
> respect, as well.

yeah, i had to write an rsh client -- arrgh ...

Re: [9fans] Fork: useless and painful?

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 202 bytes --]

Not to mention the fact that you have to send/receive on sockets
and read/write on everything else so that an app has to check
the type of any handles it is passed so that it can use the
right calls.

[-- Attachment #2: Type: message/rfc822, Size: 2698 bytes --]

From: "boyd, rounin" <boyd@insultant.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] Fork: useless and painful?
Date: Thu, 10 Jul 2003 21:57:22 +0200
Message-ID: <006601c3471d$7a06de40$b9844051@insultant.net>

> Where is the joy in computing? Win32 is making me wonder.

been there, done that.  a repeat of SysVile (sic) R3:

    you could select on a socket or poll on a stream,
    but they would not interoperate

on NT you need to call WaitForMultipleObjects() iirc and
that doesn't work on WinShlock (sic) sockets etc, so you
have to use a threaded implementation.

for extra points, if the NT CreateSocket() call finds that you
are _not_ WinShlock (sic) the call fails and returns -6 iirc.

Re: [9fans] Fork: useless and painful?

[ron minnich]

On Thu, 10 Jul 2003, David Presotto wrote:

> Not to mention the fact that you have to send/receive on sockets
> and read/write on everything else so that an app has to check
> the type of any handles it is passed so that it can use the
> right calls.

and if memory serves, sendto/recvfrom won't work on tcp sockets (they do
on *bsd)  so you not only need to have exact knowledge of it being a
socket, and what type of socket it is.

W32 is in many ways the evil counterexample to Plan 9.

ron

Re: [9fans] Fork: useless and painful?

[John Kodis]

In article <85139cb0363c3b2b1f14746d68b9ff59@plan9.bell-labs.com>,
David Presotto wrote:

>  Not to mention the fact that you have to send/receive on sockets
>  and read/write on everything else so that an app has to check
>  the type of any handles it is passed so that it can use the
>  right calls.

Nor to mention the fact that you have to pclose on process streams and
fclose on everything else so that an app has to check the type of any
streams it is passed so that it can use the right calls.

Re: [9fans] Fork: useless and painful?

[Lucio De Re]

On Mon, Jul 14, 2003 at 08:51:34AM +0000, John Kodis wrote:
>
> In article <85139cb0363c3b2b1f14746d68b9ff59@plan9.bell-labs.com>,
> David Presotto wrote:
>
> >  Not to mention the fact that you have to send/receive on sockets
> >  and read/write on everything else so that an app has to check
> >  the type of any handles it is passed so that it can use the
> >  right calls.
>
> Nor to mention the fact that you have to pclose on process streams and
> fclose on everything else so that an app has to check the type of any
> streams it is passed so that it can use the right calls.

I thought the object oriented paradigm would at least be able to hide
that from the programmer.  Weird...

++L

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> I thought the object oriented paradigm would at least be able to hide
> that from the programmer.  Weird...

one might like to think so.  the problem stems from the fact that winsock
was justa a bolt-on to windows 3 and it's always been like that.  it never
got integrated into the rest of the mess ['95/'98/NY] correctly.

windows might have a lotta C++ in it but the 'syscall' interface is classic.

it truly is a ghastly mess.

Re: [9fans] Fork: useless and painful?

[ron minnich]

On Mon, 14 Jul 2003, Lucio De Re wrote:

> I thought the object oriented paradigm would at least be able to hide
> that from the programmer.  Weird...

The weirdest thing about the "OO paradigm" is how badly it is done in so
many places.

I was looking at one "OO" os. Floppy, disk, console, etc. were all
different types of "objects", all accessed very differently. What's the
point of OO if you do that type of thing?

ron