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

Reply via email to