On 14.07.2024 11:31, Rick McGuire wrote:
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.
As you have seen, I tried to remove that dependency to the stack frame itself by creating a
StringTable that receives the stack frame-related entries in RexxActivation.hpp's "static
StringTable *getStackFrameAsStringTable(StackFrameClass *)" and which gets used to store the stack
frame information.
If analyzing the trace objects, the asynchronously dispatched messages will cause invocation entries
with no caller stack frame currently. So I was wondering, now that a StringTable representation is
possible, whether it would be o.k. to do something like the following without jeopardizing the
running system: define some StringTable field ("spawner") which is set to NULLOBJECT, but if a
message gets spawned the static method getStackFrameAsStringTable() would get invoked with the
spawner's stack frame and the resulting StringTable would be used to assign this new "spawner"
field, such that no reference to the stack frame would be needed. This way, when creating a
TraceObject and the caller's stack frame is null, one could use the activity's spawner field instead
such that the caller can be located/identified from it.
What do you think? Would that be a safe solution for tracing asynchronous
invocations?
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel