On Monday, September 21, 2020 at 11:28:33 AM UTC-5, Bill Honaker wrote:
On Sat, 19 Sep 2020 12:31:24 +1000, Tone <tss...@iinet.net.au> wrote:
On 9/19/20 5:26 AM, Bill Honaker wrote:
On Fri, 18 Sep 2020 11:55:50 -0700 (PDT), Luis Silva <hew...@gmail.com> wrote:
Hi all,
analyzing all your posts (thank you very much for all the input!!) I was able to workaround this issue. Not in an elegant way but I was able to make it work,
I had a guardian C process PROC-A that launches another c process PROC-B which opens a tcp port and waits for I/O. If I kill, stop $PROC-A (the father) $PROC-B is still shown is status *,user but if I try to send data to it via TCP (as it is is
function) it doesn't do anything. As if in a vegetative state.
The workaround was:
Instead of calling PROC-B from PROC-A (with a process launch) I call an intermediate process PROC-BYPASS via a process launch and this PROC-BYPASS calls a system(PROC-B).
This way if PROC-A dies or any of PROC-BYPASS dies the required PROC-B is still up and running
I know it is the least elegant way. I'll keep reading the manuals to see if I find a better way.
Thank you all for your help
Wolfgang made a good suggestion. Before trying to send TCP to PROC-B after PROC-A is gone,
use PTRACE against PROC-B to find out what if anything is blocking the process. Note that the '%WT'
value in the TACL STATUS tells you a little, but PTRACE is much more informative (sometimes).
If nothing is blocking, then send the TCP data, and use PTRACE again.
You may need to use the debugger against PROC-B to solve this in 'a better way'.
Bill
I think Bill meant PSTATE rather than PTRACE.
Tone is correct, PSTATE is the too to use. My apologies.
Bill
Hi all,
I've got this solved, whay I did was pass the prcoess nake to the child process, so it can make some sort or heartbeat.
If the parent dies the child process finishes it current operation and exits.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)