Re: [Oorexx-devel] A thought on multi-threaded tracing.
On 3/25/2023 11:58 AM, Rick McGuire wrote: On Sat, Mar 25, 2023 at 11:52 AM Gilbert Barmwater wrote: Let me see if I've got this. If there was a class, perhaps a subclass of outputStream, that implemented a SAY method which would "collect" the additional multi-threading information and add it to the argument that it receives, then one would only need to create an instance of that class associated with (presumably) STDERR and then change the destination of .traceOutput to be that instance. The "enhanced" trace lines would appear instead of the standard trace lines. Is that somewhat correct? Pretty much spot on. OK thanks. Some more investigation shows that Trace uses LineOut rather than Say so the class would need to implement a LINEOUT method rather than a SAY method. It would require a couple of enhancements in other places to allow the additional information to be gathered, but those would be fairly trivial to implement and also useful for situations other than TRACE. This solution requires no new TRACE command syntax, and the arguments about how much information is appropriate to add goes away because any user can choose to modify the information as they see fit. A possible implementation would be a file that contains 1) the class definition, perhaps named "enhancedTrace", with the appropriate lineOut method and 2) some prolog code that creates an instance of the class and changes the destination of .traceoutput to that instance. The user wishing to make use of this capability would then only need to ::requires the file in his program. Gil Rick Gil On 3/25/2023 8:34 AM, Rick McGuire wrote: > 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
Re: [Oorexx-devel] A thought on multi-threaded tracing.
On Sat, Mar 25, 2023 at 11:52 AM Gilbert Barmwater wrote: > Let me see if I've got this. If there was a class, perhaps a subclass > of outputStream, that implemented a SAY method which would "collect" the > additional multi-threading information and add it to the argument that > it receives, then one would only need to create an instance of that > class associated with (presumably) STDERR and then change the > destination of .traceOutput to be that instance. The "enhanced" trace > lines would appear instead of the standard trace lines. Is that > somewhat correct? > Pretty much spot on. It would require a couple of enhancements in other places to allow the additional information to be gathered, but those would be fairly trivial to implement and also useful for situations other than TRACE. This solution requires no new TRACE command syntax, and the arguments about how much information is appropriate to add goes away because any user can choose to modify the information as they see fit. Rick > > Gil > > On 3/25/2023 8:34 AM, Rick McGuire wrote: > > 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
Re: [Oorexx-devel] A thought on multi-threaded tracing.
Let me see if I've got this. If there was a class, perhaps a subclass of outputStream, that implemented a SAY method which would "collect" the additional multi-threading information and add it to the argument that it receives, then one would only need to create an instance of that class associated with (presumably) STDERR and then change the destination of .traceOutput to be that instance. The "enhanced" trace lines would appear instead of the standard trace lines. Is that somewhat correct? Gil On 3/25/2023 8:34 AM, Rick McGuire wrote: 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] A thought on multi-threaded tracing.
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
