Send using virtual circuit to process on remote node

I have a process ProcA on node 1 that sends data to process ProcB on
node 3. Periodically, the ProcA is held upto 40s. sin shows that ProcA
is REPLY_BLOCKED by the vc to ProcB on node 3. During this time the
ProcA is unavailable for processing other messages. After the 40s it
returns with errno set to 4 - unterupted function call.

I have no idea as to the cause. The circuit is setup using

pid=qnx_name_locate(“ProcB”,3,1200);

the send functions has the following

rc=Send(pid,rqst,rply,rqst_size,rply_size);
if (rc==-1)
printf(“Send Failed %d %s\n”,errno,strerror(errno);
return rc;

Any ideas as to the cause, or is there a method of foricing a process to
the READY state. I have used a timer to generate a SIGALRM signal. While
in the REPLY_BLOCKED state the signal is ignored. When the code returns
from the Send the SIGALRM signal is processed.

Padraig

Padraig Furlong <Padraig.Furlong@rte.ie> wrote:

I have a process ProcA on node 1 that sends data to process ProcB on
node 3. Periodically, the ProcA is held upto 40s. sin shows that ProcA
is REPLY_BLOCKED by the vc to ProcB on node 3. During this time the
ProcA is unavailable for processing other messages. After the 40s it
returns with errno set to 4 - unterupted function call.

I have no idea as to the cause. The circuit is setup using

pid=qnx_name_locate(“ProcB”,3,1200);

the send functions has the following

rc=Send(pid,rqst,rply,rqst_size,rply_size);
if (rc==-1)
printf(“Send Failed %d %s\n”,errno,strerror(errno);
return rc;

Any ideas as to the cause, or is there a method of foricing a process to
the READY state. I have used a timer to generate a SIGALRM signal. While
in the REPLY_BLOCKED state the signal is ignored. When the code returns
from the Send the SIGALRM signal is processed.

Has ProcB set the PPF_SIGCATCH flag? (Check the code for a call
to qnx_pflags() setting this, or check the “sin fl” output for
ProcB for this, or post the “sin fl” output for ProcB for us to
check.)

If ProcB has set this flag, then it has asked for this behaviour, that
is, it said that if a REPLY-blocked client gets hit by a signal, don’t
unblock the client until ProcB has had a chance to clean up.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Thanks David,
Checking with sin fl showed that the_PPF_SIGCATCH flag was not set. Can
this be set automatically by the watcom complier or linker or must it be
set explicitly in the code?

Padraig

David Gibbs wrote:

Padraig Furlong <> Padraig.Furlong@rte.ie> > wrote:

I have a process ProcA on node 1 that sends data to process ProcB on
node 3. Periodically, the ProcA is held upto 40s. sin shows that ProcA
is REPLY_BLOCKED by the vc to ProcB on node 3. During this time the
ProcA is unavailable for processing other messages. After the 40s it
returns with errno set to 4 - unterupted function call.


I have no idea as to the cause. The circuit is setup using


pid=qnx_name_locate(“ProcB”,3,1200);


the send functions has the following


rc=Send(pid,rqst,rply,rqst_size,rply_size);
if (rc==-1)
printf(“Send Failed %d %s\n”,errno,strerror(errno);
return rc;


Any ideas as to the cause, or is there a method of foricing a process to
the READY state. I have used a timer to generate a SIGALRM signal. While
in the REPLY_BLOCKED state the signal is ignored. When the code returns
from the Send the SIGALRM signal is processed.


Has ProcB set the PPF_SIGCATCH flag? (Check the code for a call
to qnx_pflags() setting this, or check the “sin fl” output for
ProcB for this, or post the “sin fl” output for ProcB for us to
check.)

If ProcB has set this flag, then it has asked for this behaviour, that
is, it said that if a REPLY-blocked client gets hit by a signal, don’t
unblock the client until ProcB has had a chance to clean up.

-David

Padraig Furlong <Padraig.Furlong@rte.ie> wrote:

Thanks David,
Checking with sin fl showed that the_PPF_SIGCATCH flag was not set. Can
this be set automatically by the watcom complier or linker or must it be
set explicitly in the code?

No it can’t be set automatically.

Hm… I just re-read your post…

I might have mis-comprehended what exactly was going on…


Padraig

David Gibbs wrote:

Padraig Furlong <> Padraig.Furlong@rte.ie> > wrote:

I have a process ProcA on node 1 that sends data to process ProcB on
node 3. Periodically, the ProcA is held upto 40s. sin shows that ProcA
is REPLY_BLOCKED by the vc to ProcB on node 3. During this time the
ProcA is unavailable for processing other messages. After the 40s it
returns with errno set to 4 - unterupted function call.

If ProcA is REPLY blocked, it is expected it will not be able to
process messages.

I have no idea as to the cause. The circuit is setup using


pid=qnx_name_locate(“ProcB”,3,1200);


the send functions has the following


rc=Send(pid,rqst,rply,rqst_size,rply_size);
if (rc==-1)
printf(“Send Failed %d %s\n”,errno,strerror(errno);
return rc;


Any ideas as to the cause, or is there a method of foricing a process to
the READY state. I have used a timer to generate a SIGALRM signal. While
in the REPLY_BLOCKED state the signal is ignored. When the code returns
from the Send the SIGALRM signal is processed.

Is the timeout on the SIGALRM about 40 seconds?

If so, that is why the Send() is failing with errno 4 (interrupted function
call) as you are interrupting it with a signal.

I had thought that you delivered the signal immediately, or at least soon,
but still saw ProgA blocked for a long (more than 10 seconds) time after
you had delivered the signal.

Is that not actually the case here?

The usual reason that someone ends up REPLY blocked for a long time,
is that the other end Receive()d the message, but didn’t Reply() to
the message.

Does ProcB reply to ProcA’s message? Do you check the return value
on all your Reply()s in ProcB?

While ProcA is REPLY blocked on the vc, can you post the output of:

sin
sin vc

On both nodes (that is, 1 and 3)
And tell me which node is which, and which programs are ProcA and ProcB
in the output? (I’m assuming they aren’t actually called ProcA and ProcB.)

(Oh ya, for posting, pull the text files inline, don’t attach them please.
It makes it far easier for me to respond, which means I’ll get to it faster.)

Thanks,
-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.