[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: About fathers and sons
From: |
Jose Luis Alarcon Sanchez |
Subject: |
Re: About fathers and sons |
Date: |
Sat, 12 Mar 2005 23:13:20 +0000 |
El vie, 11-03-2005 a las 15:24 -0800, Thomas Bushnell BSG escribió:
> Jose Luis Alarcon Sanchez <jlalarcon@gawab.com> writes:
>
> > - Why this "strange" way of produce processes?. In Unix init become
> > father when the original father proccess is dead, is this right?. Why in
> > Mach the processes dead so quickly while in Linux and other Unixes they
> > don't do?.
>
> What promised you that the processes would stay alive for a while?
> It's not clear what output you are seeing, because you aren't giving
> exactly what that program would print.
>
When a program is designed for do some things, it's logic suppose that
it gonna do this things and no others. If i give you the instructions
for cook "paella valenciana" and you get a cake... some was wrong. :)
> > - Where are the processes x - 3 and x - 1?. I can't understand why
> > this processes aren't into the scheme of processes production.
>
> Other processes are being created on your system at the same time;
> processes are roughly sequential, but there are no promises about the
> numbering. You cannot assume anything about it, and the ordering is
> global across the whole system. So if some other process forked in
> between your two fork calls, then this would account for what you are
> seeing.
>
What you say can be true if the execution of the binary was made 3 or
4 times. But after more than 50 times with exactly the same output i am
sure that the reason of "the lost" of this two processes are into the
program and not out, in another place of the system.
> > - About signals: in our system the macro WTERMSIG(status) returns 88
> > and the macro WSTOPSIG(status) returns 133. What are the mean of this
> > signals?.
>
> Those aren't signals, first off.
>
> You aren't ever setting or initializing the variable STATUS, so you
> can't assume anything about what it looks like.
>
> Thomas
>
My friend k0ro suggest that the explanation of this processes behavior
in the GNU/Hurd system can be caused by the procceses server and not by
the gnumach kernel. Opinions, please?.
Sincerely, thanks you, very much.
Regards.
Jose.
--
http://www.lordofunix.org
Not Registered Bee GNU/Hurd User.
Registered BSD User 51101.
Registered Linux User #213309.
Memories..... You are talking about memories.
Rick Deckard. Blade Runner.