* Ted Zeng <[EMAIL PROTECTED]> [2006-07-25T13:17:13]
> I could not figure out how to get the tool process's id. But by observing,
> I notice that its pid is 'always' equals to child process's pid+1.
It would have been helpful to see the contents of execEggplant. Is it really
using exec? If so, t
It would have been helpful to see the contents of execEggplant. Is it really
using exec? If so, the child's pid should be the same as the thing that exec'd
it.
>> Sorry. I should be more clear. My code uses ` ` (backward qoute?), which
>> is the same as system(), I think. So it is not exec
On 2006/07/29, at 4:12, Ted Zeng wrote:
...
I have used pid+1 for quite a few days now and it seems to work
without any problem. But I still feel it is not the right thing to do.
Have you ever heard of race?
I could not figure out how to get the tool process's id. But by observing,
I notice that its pid is 'always' equals to child process's pid+1.
PIDs can wrap, so there is no guarantee of this at all.
Why do you call waitpid with -1, when you know the pid you want to
wait on ($kidpid).
The reas
I don't know how the OS generate the pid for a process. That is why I don't
feel comfortable with what I did.
I am not sure if there is a race situation here.
Ted zeng
On 7/28/06 4:21 PM, "Joel Rees" <[EMAIL PROTECTED]> wrote:
>
> On 2006/07/29, at 4:12, Ted Zeng wrote:
>
>> ...
>>
>> I hav
On Jul 31, 2006, at 5:35 PM, Ted Zeng wrote:
I don't know how the OS generate the pid for a process. That is why
I don't
feel comfortable with what I did.
The way I understand it, the OS assigns the next highest available
pid when
creating a process. However, pids wrap around when they rea
--- quoth Packy Anderson:
> --- quoth Ted Zeng:
> > I don't know how the OS generate the pid for a
> > process. That is why I don't
> > feel comfortable with what I did.
>
> The way I understand it, the OS assigns the next
> highest available pid when creating a process.
It' s never specifically
Thanks for everyone who has replied.
I think Packy's solution solves my problem.
Let me restate my problem to make it clear.
Originally, my perl script launches Eggplant as a child process (use ``, not
an independent process.) so that the perl script could get the log output
from Eggplant.
But
Thanks. This is a pretty good lecture on OS's process.
You are right. The problem is the Grandchild could not be trusted.
And the child is stuck with the grandchild due to the way it launches
The grandchild.
But since the parent knows child's pid, it could use this information
To find out the gr
--- quoth Ted Zeng <[EMAIL PROTECTED]>:
> Originally, my perl script launches Eggplant as a
> child process (use ``, not an independent process.)
Actually ``, aka qx(), does spawn an independant
process. Try running:
perl -e'`sleep 6000`;' &
and then doing a `ps` to see. But the semantics of
Hi wren,
Thanks. I know better now.
I will try to fix the problem within my time limit.
Best wishes,
Ted zeng
On 8/2/06 1:18 AM, "wren ng thornton" <[EMAIL PROTECTED]> wrote:
> --- quoth Ted Zeng <[EMAIL PROTECTED]>:
>> Originally, my perl script launches Eggplant as a
>> child process (use
One way of seeing that the grandfather process can terminate
grandchild processes is to have the child process catch the signal
and kill, in turn, its own child processes, as part of its clean-up
code before it dies. This means that you have to use a signal that
can be recovered from when k
I gave this some thought. But since the child process doesn't know its child
process's pid, how could it kill the grandchild process?
ted
On 8/2/06 5:16 PM, "Joel Rees" <[EMAIL PROTECTED]> wrote:
> One way of seeing that the grandfather process can terminate
> grandchild processes is to have th
Since the child is using `` (or qx() for the pedantic), it won't know
the pid of its child, so it will have to use ps or something like it
to find out... which essentially brings us back to the kludge I
posted earlier. :(
The proper way to do this would be to, as wren suggests, fork anothe
14 matches
Mail list logo
