On Fri, Jan 21, 2022 at 10:26 AM [email protected] <[email protected]>
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 <[email protected]> wrote:
>
> 
>
>
> On Fri, Jan 21, 2022 at 9:44 AM [email protected] <[email protected]>
> 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 <[email protected]> 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 [email protected] <[email protected]>
>> 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
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>
>> _______________________________________________
>> Oorexx-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>> _______________________________________________
>> Oorexx-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
> _______________________________________________
> Oorexx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
> _______________________________________________
> Oorexx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to