#826 Race condition on loading of ::requires files.


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:


... 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.)


  • Rick McGuire

    Rick McGuire - 2009-09-26

    Please use real descriptions when opening problems. Just numbering the issues using your own number scheme is less that useful.

  • Rick McGuire

    Rick McGuire - 2009-09-26

    This is working correctly. A given routine object will only resolve its ::requires files (and run the initializers) precisely once, regardless of how many instances it might be called on. Since your program is reusing the same routine object on multiple instances, that routine object will not re-resolve its ::requires on each instance (and indeed, it has no record of which instance it has resolved it on). It is an error to assume that sort of processing dependency.



Cancel  Add attachments