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

Reply via email to