Spun off - I am sure I typed spun off (yes, forgot to switch off the spelling correction on this tablet - it wanted to ‘correct’ it again.)
René. > On 21 Jan 2022, at 17:33, rvjan...@xs4all.nl wrote: > > Ok, thanks. That helps! > I think for NetRexx, I am going the Streams route, as spun of threads are > just jvm threads, as are the ‘address’ed shells - well processes, but to > NetRexx they still run on a jvm thread. > > Best regards, > > René. > >>> On 21 Jan 2022, at 16:59, Rick McGuire <object.r...@gmail.com> wrote: >>> >> >> >> >>> On Fri, Jan 21, 2022 at 10:26 AM rvjan...@xs4all.nl <rvjan...@xs4all.nl> >>> wrote: >>> We used to call these Control Blocks, as in the interface to the OS. In >>> Rexx we can address environments. One of these is the OS shell, these have >>> data to exchange information with the addressed environments, like for >>> example how they can update the Rexx variable pool. I just wondered if >>> these all are instance variables, or whether there is some other method >>> needed to synchronise acces, for example to make sure they are not garbage >>> collected prematurely, but are when the thread using them has ended. >> >> Still not sure what you are looking for. If the external environment is the >> system one, the command gets spun off as a separate process so interactions >> like the variable pool are not possible. For other environments, the APIs >> that allow those interactions have to first obtain the global interpreter >> lock before accessing any internal data. ooRexx isn't fully multithreaded >> but rather uses cooperative multithreading. While code runs on separate >> threads, only one thread actually has access to the internals of the >> interpreter at one time. The only thing close to "a variable that controls >> access" is the kernel semaphore that controls access. >> >> Rick >> >>> >>> René. >>> >>>>> On 21 Jan 2022, at 16:12, Rick McGuire <object.r...@gmail.com> wrote: >>>>> >>>> >>>> >>>> >>>>> On Fri, Jan 21, 2022 at 9:44 AM rvjan...@xs4all.nl <rvjan...@xs4all.nl> >>>>> wrote: >>>>> Thank you Rick, >>>>> >>>>> What I meant with the last question is, are the blocks that control an >>>>> ADDRESS environment also instance variables? >>>> >>>> And I still don't understand what you are asking for. What do you mean by >>>> "blocks". I suspect you're assuming something that probably doesn't exist. >>>> >>>> Rick >>>> >>>>> >>>>> René. >>>>> >>>>>>> On 21 Jan 2022, at 15:39, Rick McGuire <object.r...@gmail.com> wrote: >>>>>>> >>>>>> >>>>>> All access to the standard handles are done via Stream object instances, >>>>>> and all of the methods are guarded so the synchronization between >>>>>> threads is automatic. I'm not sure what you are asking with the last >>>>>> question. >>>>>> >>>>>> Rick >>>>>> >>>>>> >>>>>>> On Fri, Jan 21, 2022 at 9:31 AM rvjan...@xs4all.nl <rvjan...@xs4all.nl> >>>>>>> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Some questions: >>>>>>> >>>>>>> Can anybody point me to the relevant source code that shows how ooRexx >>>>>>> ‘handles’ (no pun intended) multithreaded access to file handles; more >>>>>>> specificly (and also) how the access to the standard shell handles is >>>>>>> guarded (if at all) in the case multiple threads want to use stdin, >>>>>>> stdout and stderr. I seem to remember that say can be rerouted: are the >>>>>>> handles protected at that moment? >>>>>>> >>>>>>> In NetRexx these handles are static, so cause a bit of trouble when we >>>>>>> re-route in a heavily multithreaded environment/application like >>>>>>> Pipelines. >>>>>>> The JSR223 interface suffers likewise, as it seems to require that >>>>>>> every thread going through it can assign its own file handles. >>>>>>> >>>>>>> Also, what happens when we ‘address’ an external environment - do all >>>>>>> threads assume their own I/O handles, or are they using the same set >>>>>>> that is set centrally? >>>>>>> >>>>>>> Many thanks in advance. >>>>>>> >>>>>>> René. >>>>>>> _______________________________________________ >>>>>>> Oorexx-devel mailing list >>>>>>> Oorexx-devel@lists.sourceforge.net >>>>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>>>> _______________________________________________ >>>>>> Oorexx-devel mailing list >>>>>> Oorexx-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>>> _______________________________________________ >>>>> Oorexx-devel mailing list >>>>> Oorexx-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>> _______________________________________________ >>>> Oorexx-devel mailing list >>>> Oorexx-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> _______________________________________________ >>> Oorexx-devel mailing list >>> Oorexx-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
