On Tue, Aug 26, 2008 at 1:36 AM, Sahananda (Jon) Wolfers <[EMAIL PROTECTED]> wrote: > Just checking: > > is the proposal that if one rexx script calls another like this: > x = 'anotherRexxScript'() > then they would share .local & .environment > but if it calls like this > 'rexx.exe' 'anotherRexxScript' > then they would share .environment but not .local? > > Or, is this something that only makes a difference using the API?
No, this proposal changes none of those behaviors. The only place where this will show up is if you have an application that uses the RexxStart() API to simultaneously run multiple ooRexx programs on multiple threads within the same process. Currently, .environment and .local are shared between all of the simultaneous instances. Since elements in .local are mutable constructs (.input, .output, etc.), these can mean that these running programs can interfere with each other because of the shared .local. This proposal would introduce a level of separation between interpreter instances within the same process to prevent this type of interference. I have a sandbox version with this change working already in my sandbox, but you need to have a multithreaded application to demonstrate the differences. Rick > > thanks > > Jon > > 2008/8/26 Bill Turner, WB4ALM <[EMAIL PROTECTED]> >> >> As a "system designer" I would prefer having all RexxStart() invocations >> issued from a "parenting" process to be able to share a .environment >> while each started process would be given a separate .local >> >> Separate "Parenting" processes (started from different command windows) >> would not "share" either. >> >> This seems very logical to me. >> >> /s/ Bill Turner, wb4alm >> >> >> >> >> >> Rick McGuire wrote: >> > On Mon, Aug 25, 2008 at 6:20 PM, Mark Miesfeld <[EMAIL PROTECTED]> >> > wrote: >> > >> >> On Mon, Aug 25, 2008 at 2:39 PM, Rick McGuire <[EMAIL PROTECTED]> >> >> wrote: >> >> >> >> >> >>> 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. >> >>> >> >> Taking this a little out of order. >> >> >> >> >> >>> I can go either way. The "easy" approach is working as designed. I'm >> >>> not sure this is the correct approach, however. >> >>> >> >> I tend to agree that I'm not sure it is the correct approach either. >> >> >> >> But, I had thought that .local was not global. Is it just the way the >> >> interpreter is being started in the bug report? >> >> >> > >> > The .local vs. .environment is an artifact of the original OS/2 shared >> > memory paradigm. .environment was a single shared directory that was >> > the same in all interpreter processes. .local was a per-process >> > entity that was not visible cross processes. In the new world, >> > there's no shared memory, so the scope of .local and .environment are >> > essentially the same. Each new process creates a .local directory and >> > a .environment directory that is visible to anything running in the >> > process. >> > >> > >> >> Well a quick test shows if I start an ooRexx program in one console >> >> window and then start another ooRexx program in another window, their >> >> .local environments are separate. Would this change under your >> >> proposal? >> >> >> > >> > No, this would not change that behavior. Multiple ooRexx programs >> > running in separate processes are completely segregated by virtue of >> > the process model. What will change is a how a single application >> > that invokes multiple programs via RexxStart from within a single >> > process. Currently, these processes share a single .environment and >> > .local directory so they can interfere with each other. >> > >> > The 4.0 codebase introduces the concept of an interpreter instance. >> > Each RexxStart() API call runs in its own interpreter instance, but >> > there's not much segregation between the instances. This proposal >> > would give each RexxStart() invocation a separate .local instance (but >> > .environment is still shared across the process). Note also that this >> > will have no effect on multi-threaded ooRexx programs. Each spawned >> > thread will be added to its parent thread's interpreter instance, so >> > their behavior will remain unchanged. >> > >> > >> >>> In this new scenario, .environment remains a global entity, shared >> >>> between all interpreter instances. >> >>> >> >> Does this mean all interpreter instances in the same process space, or >> >> all interpreter instances running on the same system? >> >> >> > >> > All interpreter instances in the same process space. >> > >> > >> >> -- >> >> Mark Miesfeld >> >> >> >> >> >> ------------------------------------------------------------------------- >> >> 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 >> >> >> >> >> > >> > >> > ------------------------------------------------------------------------- >> > 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 >> > >> > >> >> >> ------------------------------------------------------------------------- >> 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 > > > ------------------------------------------------------------------------- > 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 > > ------------------------------------------------------------------------- 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
