[Oorexx-bugs] [ oorexx-Bugs-2867328 ] Program starts before requires was processed in full

[SourceForge.net <no...@so...>]

Bugs item #2867328, was opened at 2009-09-26 11:35
Message generated for change (Settings changed) made by orexx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2867328&group_id=119701

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interpreter
Group: v4.0
Status: Open
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Rony G. Flatscher (orexx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Program starts before requires was processed in full

Initial Comment:
Unfortunately, you closed issue <https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2866951&group_id=119701>, hence the need for opening a new bug. (Copying the text of the original bug report to ease finding the link to the test case).

Your assumption that the same RexxRoutineObject instance would be reused on different Rexx instances is wrong. I did not say that.

What I meant to say is, that the buffer with the Rexx code which includes the "::requires BSF.CLS" directive is the same. Each Java thread will supply this very same buffer, and BSF4Rexx *creates a new individual RexxRoutineObject* for each Java thread and then runs it. Each RexxRoutineObject will resolve the required file, *however* the program is not halted until the requires-directive has finished, which is probably the bug.

So what happens is, that the RexxRoutineObject runs the program, while the requires-directive has not finished yet.  So the BSF.CLS infrastructure has not been setup yet, as should be the case (and the reason to use the requires directive as the program depends on that infrastructure). 

If the required BSF.CLS has been fully initialized (including its prologue code having run), *before*  the Rexx program would start to run, the observed runtime errors would not occur anymore. Running "run_80_testgroup.cmd" would succeed without errors.

[P.S.: Don't know whether this is a race condition in ooRexx or not. It seems that the required program and the main program execute concurrently, hence the original qualification that this is multithreading related, without being able to conclude more at the time of filing the bug.]

Again, not being an English native speaker, if something was not explained clear enough, then please let me know and I try to rephrase it resp. explain it with different words. 

-----

File is too large to upload with this report, it is available as
"MT_bug.zip" at <http://wi.wu.ac.at/rgf/tmp/ooRexx/de_bug/>. This archive
is created for the 32-bit ooRexx interpreter. [Please note, that
accompanying files for debugging may be named "BSF4Rexx-32.*", whereas the
dll in use is named "BSF4Rexx.dll", i.e. without the bitness information.]

After download, unzip it, change into the directory "MT_bug" and run
"setEnvironment.cmd", which will set up the PATH and CLASSPATH environment
variables.

Then run the batch files:

run_80_testgroup.cmd

... this one will start a testgroup in which Rexx creates a Java object
that will create Java threads that *each create an own Rexx interpreter
instance* and run a Rexx script off it which itself will create Rexx
threads to execute and interact with BSF4Rexx.

The Rexx script contains a "::requires BSF.CLS", which was executed for the
initial Rexx interpreter instance. Each Java thread will create a Rexx
instance and run this very same Rexx program on the new instance.

>From analysing the debug output the problem in this case seems to be that
"BSF.CLS" does not get run *before* the Rexx program that requires it gets
started.

Or with other words: in a new Rexx interpreter instance the Rexx program
starts to run, before the required BSF.CLS has finished, if in another Rexx
instance that requires directive was carried out already (in the very first
Rexx instance, BSF.CLS runs before the Rexx program that requires it.).

(The last action in BSF.CLS in the prologue code is to save the class BSF
in its .local directory. This entry will be retrieved by the native code
and if it is not available, the Rexx proxy objects cannot be wrapped up as
BSF_Reference objects, leaving the encoded string as string, yielding the
given runtime error.)

If this description is not clear enough, please let me know and I try to
describe it differently. "run_80_testgroup.cmd" should run without any
errors (it is practically the same as "run_90_testgroup.cmd", except that
it uses separate Rexx interpreter instances to run the Rexx program.)

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

>Comment By: Rony G. Flatscher (orexx)
Date: 2009-09-26 12:50

Message:
Upon further investigations, I am sorry, but my bug report was wrong and is
invalid as it stands. 

The required files are processed before the program starts. 

Again sorry for the false alarm!

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

Comment By: Rony G. Flatscher (orexx)
Date: 2009-09-26 11:54

Message:
Going through the debug output here, it may be even the case that the
required file runs *after* the main program (and not concurrently). 
[Cannot say for sure due to the multithreaded nature.]

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2867328&group_id=119701