This new "bug" request is probably more of an enhancement request than
a bug. This was not something it was possible (ok, easy) to fix in
the 3.x code base, but definitely is fixable in the 4.0 version. In
fact, my initial 4.0 prototype was going to exhibit this behavior, but
I backed off from doing it out of compatibility concerns. If we're
going to do this, then the time to do it is now as part of the general
restructuring.
In this new scenario, .environment remains a global entity, shared
between all interpreter instances. However, each interpreter
instance, defined as either a RexxStart call or a call to
RexxCreateInterpreter, will get its own copy of .local. This will
include private copies of the .input, .output, and .error monitors and
its own .stdque object so that the different instances do not
interfere with each other. I do suspect it is rare that an
application would store information in ..local expecting it to be
available to other RexxStart() invocations. On the other hand, it is
extremely unexpected that calling Rxqueue('Set') in one RexxStart
instance of a server would change the queue in use by another
instance.
I can go either way. The "easy" approach is working as designed. I'm
not sure this is the correct approach, however.
Rick
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
