Re: [Sipp-devel] Next stable sipp release

[<mar...@be...>]

Olivier,
=20
I checked the diffs I sent, and the only relevant difference (except for =
more info in the error messages) is a while loop waiting for the first =
child to exit; it replaces an if statement doing the same waiting once. =
The reason for the loop is that signals (like USR2) also stop the =
waiting even if the child has not yet exited, so the waiting should =
continue in that case. As long as no signal arrives during the lifetime =
of the intermediate first child, there should be no difference at all =
between the if and the while.
=20
As the character input of the program is not handled by signals (but in =
a thread), I don't see an immediate relation (I'm no thread specialist, =
and I hope the threads do continue and not just throw away the input =
while the main program is waiting).
=20
>From the example below, I can deduce that the machine will in total =
spawn at least 4 children (one intermediate (for sipp zombie cleanup), =
one doing the command/shell (&), one sipp spawning the final one in =
background (-bg) and the final one). This can take some time for the =
machine to be ready with it, and as long as the first child has not =
exited, the main process will wait.
=20
Is it this waiting time that is meant with "on the first instance", or =
is there a first keystroke not being handled?
=20
So, please give some more info on the difference in behaviour between =
the two versions. Did you ever get a "waitpid error" in revision 279 =
(only in this case the loop is entered)?=20
=20
   Best regards,
=20
   MarcVD

________________________________

From: Boulkroune, Olivier (Non-HP:Atos Origin) =
[mailto:oli...@hp...]=20
Sent: 23 July 2007 18:49
To: mar...@be...
Cc: sip...@li...
Subject: RE: [Sipp-devel] Next stable sipp release



Marc,

=20

It seems this commit brought the following problem :

=20

I have a scenario where one sipp instance launches two other sipp =
instances in 3pcc, something like

=20

<nop>

    <action>

      <exec command=3D"/sipp XXXX:5060 -i [LOCAL_IP] -p [field8] -s =
[field0] -sf 3pccSut.xml -fd 60 -3pcc XXXX:[field12] -r =
[CALLRATE_CONFERENCEE] -m [field4] -l [field4] -mp [field9] =
[TRACES_CONFERENCEE_SUT] -base_cseq 200 -aa -bg &"/>

    </action>

  </nop>

=20

When the command has been executed, the 'p' and 'q' keys press does not =
work anymore on the first instance. The problem occurs since revision =
280 (revision 279 works fine).

Could you have a look on this ?

=20

Thans and regards,

=20

Olivier Boulkroune

=20

________________________________

De : sip...@li... =
[mailto:sip...@li...] De la part de =
Boulkroune, Olivier (Non-HP:Atos Origin)
Envoy=E9 : jeudi 12 juillet 2007 09:57
=C0 : mar...@be...
Cc : sip...@li...
Objet : Re: [Sipp-devel] Next stable sipp release

=20

1)       Checked-in (rev 280).

=20

Thanks a lot Marc.

=20

Olivier Boulkroune

=20

________________________________

De : mar...@be... [mailto:mar...@be...]=20
Envoy=E9 : jeudi 12 juillet 2007 09:06
=C0 : Boulkroune, Olivier (Non-HP:Atos Origin)
Cc : sip...@li...
Objet : Re: [Sipp-devel] Next stable sipp release

=20

Olivier,=20

1)  there should still be a bug fix hanging around for "sipp fix for =
interrupted waitpid() case" (mail of mine dated 14/05/2007), at least I =
didn't get/see any reaction on this until now.

2) sorry, I didn't find the time yet to look at the extra ^M (<CR>) =
generated when launching unix commands.=20

  Best regards,=20

  MarcVD=20

(-: from Marc VAN DIEST (BELGACOM) +32 2 244 5078 ;-)=20