Re: Ask for help about wait() for several processes in C ,solaris

From: Edward G. Nilges (spinoza1111_at_yahoo.com)
Date: 01/01/04 

Date: 1 Jan 2004 11:28:28 -0800

Randy Howard <randy.howard@FOOmegapathdslBAR.net> wrote in message news:<MPG.1a5da8592c7398ff989a6a@news.megapathdsl.net>...
> In article <f5dda427.0312312327.178b2827@posting.google.com>, spinoza1111
> @yahoo.com says...
> > I did take a look, as a unix and C amateur I see that unix man pages
> > on the Web explicitly allow for zombie children which have exited
> > before the wait, but contain no language that implies that the child
> > may not have fully started when the process ID is returned. OK, I can
> > admit that the possibility I raised was a red herring and I certainly
> > apologize for this.
>
> Thank you. I'm impressed that you can admit a mistake, I haven't seen
> this before from you.
>
> > I also see what Randy Howard was talking about about the differences
> > between what he calls processes and what he calls threads, perhaps in
> > the difference between fork and clone. Windows has a different
> > terminology in which the relation between process and thread is one to
> > many.
>
> It is clear that you still do not see the difference. fork() has
> nothing to do with threads directly. They aren't my definitions, they're
> the usual definitions used by all modern threaded programmers. I
> think perhaps a letter-writing campaign to Apress to stop this
> before it spreads to others is in order. What's the name of the
> guy responsible for editing your book at Apress?

This is a legally actionable threat. But my lawyer has advised me that
such threats, when based on public access newsgroup content, have been
treated as complete jokes since Matt Drudge wasted the public's
attention with a private, consensual relationship, and that for this
reason I should be unconcerned.

As it happens, my book doesn't have to do at all with threads. It has
to do with how to write the front-end of a compiler.

Were I to write about threads (see below) I would use an internally
consistent terminology since whatever you believe, there is no
"natural" connection between the word and the thing. Instead, my
post-structuralism teaches me that the words are labels for what
happens. The post-structuralist question, which is answered
differently for different operating systems, is whether the OS
developers have identified the thread/process relationship as
one-to-one, many-one, or one-many.

Furthermore, it's clear that it is you who are confused when you don't
see the commonality from the standpoint of reliability. The OP used
poor practice, including the use of constants in place of symbols and
hard coded sleeps, which I could see even as a nonspecialist...in part
because I'd just unsnarfed a serial communications driver in C# which
misused Windows processes and Windows threads.

I did so by using a standardized approach to objects which recognized
the need to classify them as not threadable by default,
multithreadable when run in different instantiations, fully threadable
or stateless, in a continuum. The result was a working interface in
contrast to something which was out of control.

>
> > I am still very impressed by the way in which fork implements
> > multithreading from the standpoint of sheer elegance.
>
> OH MY GOODNESS. You really don't get it, do you? THREADS != PROCESSES
> except for the trivial subcase where a process has only one thread.

This really is nonsense. The fork creates a process. The concerns are
the same at the level I was concerned because BOTH threads and
processes compete for time, and the issues have to be mastered in both
areas.

I agree that if I were to implement a fork() as a thread creation in
my compiler, this would be confusing and for this reason, I will not
give it this name. At some point I will implement a primitive with a
different name to allow the user to experiment with the concept.

Your point, absent the silly threats, is accepted.

> I highly recommend that you read "Programming with POSIX Threads" by
> David Butenhof. Even though it is not directly applicable to the
> Windows thread model, pthreads has been implemented on top of Windows
> threads, and besides, the definitions, explanations and coverage of
> the primary issues in threading programming are explained very well
> in that book. It'll make you a better programmer if you read it,
> regardless of the OS you intend to develop multithreaded programs
> upon.
>
Thanks for the reference.

I do notice, all the time, hysterical reactions on the part of
programmers with some experience in multiple threads and multiple
processes to programmers who they think have no experience or
alternatively academic training (I have both).

It is based on a genuine and valid fear of the real problems that can
occur (Dan Appleman has a good discussion of the way they occur in the
CLR in one of his books on .Net programming).

But note that mastering terminology is not the solution.

The solution happens to be getting people to avoid poor practice in
the small yet one continually sees multiple threads and multiple
processes implemented with (1) random constant sleeps, (2) comparision
against constants and (3) avoidance of mutex and semaphores.

The Solaris documentation explicitly says that the children created by
a fork() might deadlock if they do anything beyond a simple call yet
mutex wasn't used in the OP's code.

Whereas my discovery in .Net was that I had, inside objects intended
to race each other in threads, to compulsively use the equivalent of
mutex.
 
> > Plus I admit that it is probably too much work for the OP to wade
> > through my prose to get to anything useful.
>
> This is the largest understatement since the big bang. Once again I
> am stunned by your frank admission however. At this point, I am
> starting to suspect a sock-puppet is in our midst, or you hit the
> alcohol way too heavy on New Year's Eve and accidentally left your
> troll-filter unconnected.
>
You are stunned only because you think you understand what's going on
and you do not.
 
> > Yet they seemed to naturally get along and naturally confab without
> > calling each other names, and perhaps this is why they are more
> > productive than spoiled rotten US developers, who can't confab even in
> > nice, air conditioned offices, or remotely on the Web, without jumping
> > on style and issues of microefficiency.
>
> Actually, I've never had to work in a group that could not get along
> well. When anyone was around that displayed your level of incompetence
> and complete unwillingness to listen to reason or improve, they were
> simply terminated. Problem solved. My head spins at the lovely way
> "terminated" is overloaded in the English language.

That's not been my observation, and it hasn't been PJ Plauger's,
either. Perhaps in "safe" government installations, wasting taxpayer
money on Solaris workstations that could be replaced by Windows 2000,
everybody gets along. But in the real world of "employment at will",
programmers are so afraid for their positions that they no longer are
able to work together, and the result is the 80% failure rate I have
described.

Relevant Pages

  • Re: Ask for help about wait() for several processes in C ,solaris
    ... >> the usual definitions used by all modern threaded programmers. ... The fork creates a process. ... > programmers with some experience in multiple threads and multiple ... Oh never mind, terminology doesn't matter. ...
    (comp.programming)
  • Re: fork and signals are so "Unixy"
    ... like this: windows doesnt fork processes. ... Basically this function combines fork with exec, ... Also note that in Windows using multiple threads is much more common ... also used in situations where in Posix one would be likely to use fork. ...
    (comp.os.minix)
  • Re: Simple New Ruby Programmer Problem with $stdin.gets
    ... the mark of a professional programmer to work with any environment. ... Programmers, myself included, tend to ... the Windows environment. ... programmers use the command line to run programs. ...
    (comp.lang.ruby)
  • Re: Cleaning and maintaining the registry
    ... > Kerry Brown wrote: ... Windows 2000 and XP store the registry in several files. ... but with so many programmers thinking their way ...
    (microsoft.public.windowsxp.general)
  • Re: huge array
    ... I try to avoid unmanaged calls when I can - especially to the windows ... XPSP1 support ended 3 years ago. ... You like to talk about Mono on Linux but Mono is not ... demoting 3rd-party programmers and providing ...
    (microsoft.public.vb.general.discussion)