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
