On Sun, Jul 14, 2024 at 5:28 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:
> On 13.07.2024 17:31, Rick McGuire wrote:
>
> That makes absolutely no sense. Once the new activity is started, there is
> no guarantee that the stackframe or even the activity from which it was
> spawned even exists any more. The original activity has continued on doing
> its own stuff.
>
> A question here: I thought that if storing Rexx objects in a Rexx
> collection they are pinned and do not get garbage collected.
>
The stack frame object would not be garbage collected, but the stack frame
itself and the things that it referred to would no longer exist or be
valid.
> Your statement about the possibility of a stackframe to not exist anymore
> seems to indicate that a StackFrame object could be garbage collected while
> being referred to in a Rexx collection?
>
> The reason for this question is the following scenario: running Rexx
> programs for tracing, creating trace logs that will get analyzed way after
> the traced program has finished running. In that scenario the traceObjects
> that are collected in an array need to be processed and at that time will
> analyze the stackframe entry to learn about the package name, line numbers
> and the like. What would happen then if accessing the stackframe entries at
> that point in time?
>
> ---rony
>
>
>
> On Sat, Jul 13, 2024 at 11:09 AM Rony G. Flatscher <
> rony.flatsc...@wu.ac.at> wrote:
>
>> On 13.07.2024 16:27, Rick McGuire wrote:
>>
>> the stackframes are a representation of the activations active on an
>> activity. When a method is started asynchronously, it is the base of the
>> activity stack and does not have a parent stack frame. So many other things
>> would get messed up by trying to add one to that stack. And you're on your
>> own with fixing any problems created by trying to add one.
>>
>> Hmm, o.k., thanks.
>>
>> Would there be another source from where one could learn at runtime where
>> an activity got created from that could be used instead? Or would it be
>> possible to add "just" a field to Activity that would allow to refer to an
>> Activity's creator's stack frame, if available?
>>
>> ---rony
>>
>>
>> On Sat, Jul 13, 2024 at 9:15 AM Rony G. Flatscher <
>> rony.flatsc...@wu.ac.at> wrote:
>>
>>> While analyzing various invocation types and the caller's stack frame
>>> (for invocation entries to allow identifying the caller from a trace log
>>> later), everything seems to work out nicely.
>>>
>>> There is one case where the caller's stack frame cannot be generated, it
>>> seems to have to do with methods that get run asynchroneously, e.g.:
>>>
>>> ...
>>> o=.clz~new
>>> o~m1 -- caller's stack frame can be built for ">I> Method "M1"
>>> with scope ..."
>>> o~start("m1") -- caller's stack frame can NOT be built for ">I> Method
>>> "M1" with scope ..."
>>> ...
>>>
>>> The activity for the asynchronous message has Activity::activationFrames
>>> as NULL, such that it cannot be used for creating a parent stack frame.
>>>
>>> Would it possible to supply an Activity::activationFrames for
>>> asynchronous dispatch?
>>>
>>> ---rony
>>>
>>> _______________________________________________
> 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
