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.
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 <[email protected]> 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? ---ronyOn Sat, Jul 13, 2024 at 9:15 AM Rony G. Flatscher <[email protected]> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
