So it turns out that under Windows, it is easy to obtain the thread ID
of the current running code. My framework now does that so it might be
of use, as is, to anyone needing to know which thread executed the line
being traced. Gil
On 4/1/2023 5:01 PM, Gilbert Barmwater wrote:
Well, FWIW, I thought so too. Just for fun I have implemented a
working framework of what I described later in this thread. Of
course, even though it can modify the trace output, it does not
actually put the "real" values in as that would require either the
modifications to the .stackframe class that Rick describes or a native
method that could obtain and return them. I haven't written either at
this point.
Gil
On 4/1/2023 12:01 PM, Rony G Flatscher wrote:
That sounds very interesting!
—-rony
Rony G. Flatscher (mobil/e)
Am 25.03.2023 um 07:35 schrieb Rick McGuire <object.r...@gmail.com>:
I had one of those AHA moments this morning. The whole question
about multithreaded tracing can be quite cleanly resolved by
removing the question from the TRACE command entirely.
Currently, the trace output is written to the .TRACEOUTPUT monitor.
With a few small enhancements to already existing classes, it would
be possible for any additional information to be added by the
TRACEOUPUT target. To enable it, one would only need to push a new
output destination to the monitor. The new destination would add any
additional debug information to the trace lines. This is not only
pretty simple, but it also means any user can customize the trace
information to their own requirements, though it would be nice to
supply a couple of builtin alternatives.
The enhancements necessary to do this are pretty simple. The
StackFrame class already has most of the information you need for
debugging, but it could use methods to expose a threadid, instance
id, and also the current GUARD status in the case of method calls.
This can be quite easily done, and would provide useful debug
information for more than just the trace output. It might be
desirable to add the same methods to .Context. I can go either way
with that one.
Rick
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
