Re: Alarms and signals

Yes Scott, you guessed everything right.Thought I had made everything
clear.

I have a single program running as a socket server with a C module running
threads, one per connection. One RPG module that provides services to the C
code running under *SERIALIZE. Everything that runs in their is critical
code, ie only one thread at a time can be in there.

I could have written the RPG part in C also but it is some hairy code and I
am not that good of a C programmer (grin).

I then have environment jobs that are spawned out. They are just standard
ILE RPG programs. They receive messages from recvmsg and sendmsg calls and
perform functions.

As I said my previous e-mail, the alarm and timeout works in the
environment jobs so must be the signals being blocked. Was just hoping you
might have a way around it.


On Thu, Jul 27, 2017 at 10:35 PM, Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
wrote:

Alan,

I'm not sure I understand your scenario. You say the RPG code is
"running as part of a C program". I would assume that means you have
one program written with multiple modules, the main module is C, and
another module is RPG. (Which technically is not a "C program", it's
just a program made with C and also RPG... but that's what I figured
you meant.)

But... then you say they are communicating with sendmsg/recvmsg, which
would make any sense if they are modules in the same program. You
wouldn't use sockets like this unless they were running in separate jobs...

Though, maybe you have multiple instances of this program running in
separate jobs, I guess? Please clarify what you mean, here.

As for why you aren't getting an EINTR and your handler isn't firing...
hard to say...

Maybe your job has signals blocked... or, at least the SIGALRM signal
is blocked? I know that CGI jobs, for example, have this blocked so you
can't use signals there. That is one of the reasons I never use them
anymore.

Also -- I'm not sure if I've ever used SIGALRM with sendmsg/recvmsg. I
typically use alarms with TCP sockets, not UNIX domain sockets. I'm
telling you this because I don't know if they work? They might or might
not... I haven't tried.

Maybe you should try using poll or select instead?

-SK


On 7/27/17 10:26 PM, Alan Campin wrote:

I have a piece of RPG code that is running as part of a C program. The
code
is critical code and only one thread at a time can execute it.

I sendmsg and recvmsg to send message between two job.

All works perfectly if that other job is still there but when that job
dies
or crashes and I attempt to a recvmsg, it hangs forever.

To avoid that problem, I am using signals Scott has discussed.

I enable the signals and then issue an alarm before I issue the recvmsg.

If I use 1 second and their is nothing out there I would expect for the
recvmsg to hang which it does but the alarm never fires.

I am trying to figure out why the alarm is not firing. Is it possible the
alarm doesn't work because the RPG code was called from a thread in C
code?

I just tired some test code that had one program spawn another program and
I did an alarm in that job and it worked so that tells me that the fact
that I am running in a multi-threaded environment must be what is causing
the problem.

I am using Thread(*SERIALIZE) for the RPG module.

Any help would be appreciated.

Qp0sEnableSignals();
sigemptyset(act.sa_mask);
sigaddset(act.sa_mask: SIGALRM);
act.sa_handler = %paddr(GotAlarm);
act.sa_flags = 0;
act.sa_sigaction = *NULL;
sigaction(SIGALRM: act: *omit);

0151.00 Alarm(InTimeout);
0152.00 If RecvMsgApi(InSocket:MsgHdr:0) < 0;
0153.00 GetLastError(ErrorNumber:
0154.00 Msg);
0155.00 Qp0sDisableSignals();
0156.00 If ErrorNumber = EINTR;
0157.00 %Len(Msg) = 0;
0158.00 Return Msg;
0159.00 EndIf;
0160.00

dcl-proc GotAlarm;

dcl-pi *N;

InSignalNumber Int(10) Value;

end-Pi;



// Do nothing. The API will return EINTER("interrupted by signal")
when
// the signal is received.



end-proc;

--
Scott Klement
http://www.scottklement.com
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD