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