Object Rexx, REXXSTART, and semaphores under OS/2. 
Author Message
 Object Rexx, REXXSTART, and semaphores under OS/2.

Hi all!

I have a question, and perhaps an observation.

There's an issue with the ORexx implementation on OS/2, when using
the REXXSTART call to call rexx from an executable.

Whenever REXXSTART is used to call some REXX code, it opens four
semaphores. However, in classic rexx, once the called script
terminates, the semaphores are closed. When one's using object rexx,
the semaphores are left open until the program terminates.

This can cause havoc if the program is a daemon... I have one that
uses rexxstart once a second at minimum (to provide a user exit),
and it will toast the system in about four hours unless the user
exit is disabled, as all those semaphores end up using up all the
kernel heap memory.

I've passed this on to the OS/2 fix guys, and what they told me is
that it has to be handled differently under OS/2 than under Linux or
Windows because Rexx is implemented as a DLL... and since it
supports threading, they can't close the semaphores in case they're
needed by the called script. The idea is that if a called script
starts a thread, that thread can continue to execute even if the
"main" part of the script terminates.

So... this leads next to the question of "the workaround";). Is
there a way for the calling program to be able to get a handle for
those semaphores, and perhaps pass them to the called script?

The thinking behind this is that object rexx has calls for handling
semaphores, including a couple that can be used to close them. It
seems to me that if there was a way for the called script to know
how to get to the semaphores, they could then be explicitly closed
by the calling script. I was thinking that perhaps they could be
passed as arguments...

/* sample.cmd - sample prog that closes sems passed as args */

use arg stuff sem1 sem2 sem3 sem4

do stuff
  then do more stuff ...
end

call syscloseeventsem(sem1)
call syscloseeventsem(sem2)
call sysclosemutexsem(sem3)
call sysclosemutexsem(sem4)

/* eof */

or whatever may be the appropriate call, depending on the type of
semaphore we're talking about here.

The advice I got was to create a separate executable to start the
script... when that executable terminates, then the semaphores will
die with it. However, that might just as well be cmd.exe... and the
idea behind using rexxstart is to get more performance, which would
be defeated by such a mechanism anyway.

Does this strike anyone as feasible? Are there other approaches that
others might be able to suggest?

I'm not a C programmer, but I sure like object rexx for my CGIs, and being
able to get more performance by avoiding cmd.exe would be good...
I'm hoping that I can help find a good methodology that would permit
developers avoid this particular problem with their software in the
future...

Regards,

Jack

--
-------------------------------------------------------------------
* Jack Troughton                            jake at consultron.ca *
* http://www.*-*-*.com/                         irc.ecomstation.ca *

-------------------------------------------------------------------



Thu, 09 Dec 2004 02:01:01 GMT  
 Object Rexx, REXXSTART, and semaphores under OS/2.
Doesn't calling the RexxWaitForTermination API solve the problem?

It strikes me that your "suggestion" is asking for big trouble.


Quote:
> Hi all!

> I have a question, and perhaps an observation.

> There's an issue with the ORexx implementation on OS/2, when using
> the REXXSTART call to call rexx from an executable.

> Whenever REXXSTART is used to call some REXX code, it opens four
> semaphores. However, in classic rexx, once the called script
> terminates, the semaphores are closed. When one's using object rexx,
> the semaphores are left open until the program terminates.

> This can cause havoc if the program is a daemon... I have one that
> uses rexxstart once a second at minimum (to provide a user exit),
> and it will toast the system in about four hours unless the user
> exit is disabled, as all those semaphores end up using up all the
> kernel heap memory.

> I've passed this on to the OS/2 fix guys, and what they told me is
> that it has to be handled differently under OS/2 than under Linux or
> Windows because Rexx is implemented as a DLL... and since it
> supports threading, they can't close the semaphores in case they're
> needed by the called script. The idea is that if a called script
> starts a thread, that thread can continue to execute even if the
> "main" part of the script terminates.

> So... this leads next to the question of "the workaround";). Is
> there a way for the calling program to be able to get a handle for
> those semaphores, and perhaps pass them to the called script?

> The thinking behind this is that object rexx has calls for handling
> semaphores, including a couple that can be used to close them. It
> seems to me that if there was a way for the called script to know
> how to get to the semaphores, they could then be explicitly closed
> by the calling script. I was thinking that perhaps they could be
> passed as arguments...

> /* sample.cmd - sample prog that closes sems passed as args */

> use arg stuff sem1 sem2 sem3 sem4

> do stuff
>   then do more stuff ...
> end

> call syscloseeventsem(sem1)
> call syscloseeventsem(sem2)
> call sysclosemutexsem(sem3)
> call sysclosemutexsem(sem4)

> /* eof */

> or whatever may be the appropriate call, depending on the type of
> semaphore we're talking about here.

> The advice I got was to create a separate executable to start the
> script... when that executable terminates, then the semaphores will
> die with it. However, that might just as well be cmd.exe... and the
> idea behind using rexxstart is to get more performance, which would
> be defeated by such a mechanism anyway.

> Does this strike anyone as feasible? Are there other approaches that
> others might be able to suggest?

> I'm not a C programmer, but I sure like object rexx for my CGIs, and being
> able to get more performance by avoiding cmd.exe would be good...
> I'm hoping that I can help find a good methodology that would permit
> developers avoid this particular problem with their software in the
> future...

> Regards,

> Jack

> --
> -------------------------------------------------------------------
> * Jack Troughton                            jake at consultron.ca *
> * http://consultron.ca                         irc.ecomstation.ca *

> -------------------------------------------------------------------



Thu, 09 Dec 2004 15:47:47 GMT  
 Object Rexx, REXXSTART, and semaphores under OS/2.

Quote:

>Doesn't calling the RexxWaitForTermination API solve the problem?

What RexxWaitForTermination API?  (Please note the subject, he is
looking for a solution on OS/2, where this API does not seem to be
available.)
--

Team OS/2
http://lafaix.online.fr


Thu, 09 Dec 2004 17:30:38 GMT  
 Object Rexx, REXXSTART, and semaphores under OS/2.
I saw the title. The API is available for OO-REXX on OS/2, but not for
classic REXX. Jack clearly stated that he was using OO-REXX, and that the
problem only occurs on that implementation.


Quote:


> >Doesn't calling the RexxWaitForTermination API solve the problem?

> What RexxWaitForTermination API?  (Please note the subject, he is
> looking for a solution on OS/2, where this API does not seem to be
> available.)
> --

> Team OS/2
> http://lafaix.online.fr



Thu, 09 Dec 2004 23:31:09 GMT  
 Object Rexx, REXXSTART, and semaphores under OS/2.

Quote:

>I saw the title. The API is available for OO-REXX on OS/2, but not for
>classic REXX. Jack clearly stated that he was using OO-REXX, and that the
>problem only occurs on that implementation.

Well, I looked it up... it's not in the docs in the toolkit.

It doesn't look like it will solve the problem. First of all, you
don't really want to have a daemon pause while it's running a rexx
script... the docs say:

"RexxWaitForTermination waits for the termination of all activities
of the program that were started by RexxStart. This function puts
your program into a wait state. It cannot continue until the
activities have finished."

This would seem to indicate that the calling program will pause
while the script is executing. Also, a large part of the problem is
that the called script terminates, but that the semaphores don't get
deallocated... how does this call fix that?

I also saw the RexxDidRexxTerminate function. It looks like it might
be a bit more useful, in that the calling program can continue to
execute.

Here's a question... do you know if the RexxWaitForTermination call
only pauses the thread that's making the call, or the entire
program?

Also, it looks like the RexxDidRexxTerminate function allows further
processing after the rexx prog is finished... I imagine that this
could be used to clean up the open semaphores, no? How would one go
about getting handles to those semaphores?

Does anyone know of a good way for the calling program to find out
which interpreter they're running? I suppose that a call to the rexx
variable "value" would be enough to do that...

I'm pretty much a newbie at this stuff, so if I'm asking really
elementary questions, sorry.

Quote:




>> >Doesn't calling the RexxWaitForTermination API solve the problem?

>> What RexxWaitForTermination API?  (Please note the subject, he is
>> looking for a solution on OS/2, where this API does not seem to be
>> available.)
>> --

>> Team OS/2
>> http://lafaix.online.fr

--
-------------------------------------------------------------------
* Jack Troughton                            jake at consultron.ca *
* http://consultron.ca                         irc.ecomstation.ca *

-------------------------------------------------------------------


Fri, 10 Dec 2004 02:32:12 GMT  
 Object Rexx, REXXSTART, and semaphores under OS/2.

% "RexxWaitForTermination waits for the termination of all activities
% of the program that were started by RexxStart. This function puts
% your program into a wait state. It cannot continue until the
% activities have finished."

Sure, but since all the activities have finished, this should amount
to no wait at all.

% This would seem to indicate that the calling program will pause
% while the script is executing. Also, a large part of the problem is

But that happens with RexxStart anyway, non? The caller waits for the
script to terminate. The difference with Object Rexx is the script
might spawn a child thread which keeps going and going.

% that the called script terminates, but that the semaphores don't get
% deallocated... how does this call fix that?

My guess is that it waits for them to be signalled, then releases them.
I have to assume this is why the semaphores exist. There ought to be
another API RexxIDontCareIfTheStupidThingNeverTerminates which just
releases the semaphores.

% Also, it looks like the RexxDidRexxTerminate function allows further
% processing after the rexx prog is finished... I imagine that this
% could be used to clean up the open semaphores, no? How would one go
% about getting handles to those semaphores?

I'm just guessing based on my knowledge of similar APIs, but I assume
this will tell you if calling RexxWaitForTermination would block or
not, but that it will do nothing to clear up the semaphores.

--

Patrick TJ McPhee
East York  Canada



Sat, 11 Dec 2004 09:13:11 GMT  
 Object Rexx, REXXSTART, and semaphores under OS/2.

Quote:


>% "RexxWaitForTermination waits for the termination of all activities
>% of the program that were started by RexxStart. This function puts
>% your program into a wait state. It cannot continue until the
>% activities have finished."

>Sure, but since all the activities have finished, this should amount
>to no wait at all.

Not necessarily... it is a good idea to allow for the possibility
that people will actually start threads, I think. I could certainly
see a use for that in certain situations.

Quote:
>% This would seem to indicate that the calling program will pause
>% while the script is executing. Also, a large part of the problem is

>But that happens with RexxStart anyway, non? The caller waits for the
>script to terminate. The difference with Object Rexx is the script
>might spawn a child thread which keeps going and going.

This is the crux of the issue... actually, I'm not sure that
rexxstart waits... oh I get it... the "main" thread of the called
script is done, and so the calling program continues on its merry
way, but if the "main" thread of the called script started a thread
(eg, to process a print job or some such) then those semaphores need
to be there in case that thread requires it.

One would think that the interpreter _should_ be smart enough to
figure out once all the threads are done, but I guess I can see why
it may not be able to do so.

So, what you're suggesting is that adding in the RWTF (that name's
just too long for casual conversation) will not result in any
greater blocking than would normally occur with rexxstart... unless
the program called spawns a thread.

Ok, I can see a problem... if someone uses a rexx script to start
The Neverending Thread then the program will essentially stop dead.

OTOH, at least it's something that can be fixed by the user, and can
be documented as something to avoid.

Quote:
>% that the called script terminates, but that the semaphores don't get
>% deallocated... how does this call fix that?

>My guess is that it waits for them to be signalled, then releases them.
>I have to assume this is why the semaphores exist. There ought to be
>another API RexxIDontCareIfTheStupidThingNeverTerminates which just
>releases the semaphores.

Well, I would think you could possibly end up with zombie threads if
you did that... would explain why they didn't add that particular
api:)

Quote:
>% Also, it looks like the RexxDidRexxTerminate function allows further
>% processing after the rexx prog is finished... I imagine that this
>% could be used to clean up the open semaphores, no? How would one go
>% about getting handles to those semaphores?

>I'm just guessing based on my knowledge of similar APIs, but I assume
>this will tell you if calling RexxWaitForTermination would block or
>not, but that it will do nothing to clear up the semaphores.

So... what could be done is something like this:

At program initialisation:

call rexxstart (parse version)
        /* Figure out what kind of rexx is running */

if rexx = object rexx, then (call it like this)

call rexxstart {blah}

/* Program runs and main thread returns */

while (!RexxDidRexxTerminate()) {

        RexxWaitForTermination()

Quote:
}

Assuming that the RexxWaitForTermination call does indeed fix up the
problem with semaphores, this should solve the problem completely.

Does anyone know if in fact neither the RexxDidRexxTerminate nor the
RexxWaitForTermination take arguments? The docs don't seem to
indicate that they do, but I have to wonder... if a program is
starting more than one rexxstart at a time (on separate threads) how
do the calls keep track of which rexxstart call (and associated
activities) that a particular call is supposed to follow up on?

Thanks very much for jumping in on this...!

Regards,

Jack

--
-------------------------------------------------------------------
* Jack Troughton                            jake at consultron.ca *
* http://consultron.ca                         irc.ecomstation.ca *

-------------------------------------------------------------------



Sat, 11 Dec 2004 10:02:30 GMT  
 Object Rexx, REXXSTART, and semaphores under OS/2.

Quote:


>% "RexxWaitForTermination waits for the termination of all activities
>% of the program that were started by RexxStart. This function puts
>% your program into a wait state. It cannot continue until the
>% activities have finished."

>Sure, but since all the activities have finished, this should amount
>to no wait at all.

<snip>

BTW- I've been looking for which library has those two functions in
it... I've been using exeinfo. Do you (or anybody else) know which
library has those functions? My attempts to find it in one of the
rexx libs (rexx.dll, rexxapi.dll, etc) have so far met with abject
failure:)

To be clear... I'm looking for RexxDidRexxTerminate and
RexxWaitForTermination. Does anyone know where they are?

TIA!

Regards,

Jack

--
-------------------------------------------------------------------
* Jack Troughton                            jake at consultron.ca *
* http://consultron.ca                         irc.ecomstation.ca *

-------------------------------------------------------------------



Sat, 11 Dec 2004 10:37:54 GMT  
 Object Rexx, REXXSTART, and semaphores under OS/2.

Quote:
> Does anyone know if in fact neither the RexxDidRexxTerminate nor the
> RexxWaitForTermination take arguments? The docs don't seem to
> indicate that they do, but I have to wonder... if a program is
> starting more than one rexxstart at a time (on separate threads) how
> do the calls keep track of which rexxstart call (and associated
> activities) that a particular call is supposed to follow up on?

They take no arguments. They wait for the rexxstart on the same thread. You
should therefore wait for termination of the previous rexxstart before
running the next REXX.


Sat, 11 Dec 2004 14:13:17 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Windows Event Semaphores under Object REXX on W98

2. OS/2 Rexx port to Object Rexx for NT

3. OS/2 Rexx port to Object Rexx for NT

4. VX-REXX and Object REXX under OS/2

5. Object REXX & VX-REXX under OS/2

6. OS/2 Object REXX (ORX) - how to get DLL to update REXX variable

7. Conversion OS/2 Rexx to Object Rexx for Windows '95

8. OS/2 REXX Question (Object REXX Question Inside)

9. OS/2 rexxstart() question....

10. Using REXX to create new objects in OS/2 with Desktop Observatory

11. WPS classes in Object Rexx OS/2

12. Manipulating OS/2 Desktop Objects through REXX

 

 
Powered by phpBB® Forum Software