help-hurd
[Top][All Lists]
Advanced

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]