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?
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
