This proposal attempts to meet with the discussions that have been taking place in the past years
regarding supplying multithreaded related trace information to regular trace. In the following the
multithreaded related trace information is referred to as "mtPrefix" (multithreaded prefix) meant to
be placed before the formatted trace line.
A few remarks upfront:
* having by default mtPrefix active was seen as problematic,
* using an environment variable to activate mtPrefix was not seen to be
desirable,
* Rick came up with the idea of allowing the Rexx programmer to define his own
mtPrefix.
The proposal for a multithreaded trace prefix ("mtPrefix") is as follows:
* define a TraceObject class as a subclass of StringTable with a makeString
method that yields the
trace line by default,
* define a class attribute on TraceObject by the name of "mtPrefix". If the
programmer sets the
value to .true, then the mtPrefix will get prepended to each trace line by
default until the
value gets changed to .false; this allows the Rexx programmer full control
such that mtPrefix
can only be triggered intentionally,
* ooRexx should create a traceObject in "Activity::traceOutput(...)" filling
in the trace line and
all mtPrefix related information with the following index and values:
o
index: value:
TRACELINE a string
INSTANCE a number (interpreter instance, led in by default:
"R")
THREAD a number (activity, led in by default: "T")
INVOCATION a number (activation, led in by default: "I")
VARIABLEDICTIONARY a number, if 0 then the remainder are not stored (led in by
default: "V")
ISGUARDED .true or .false
LOCKCOUNT a number (reservecount, led in by default: "L")
ISLOCKED .true or .false
o the default mtPrefix in TraceObject should supply all information in the
following format to
allow full analysis of the most complex multithreaded Rexx programs:
"[R1 T1 I5 G V1
L2 *]" where the first three words will always be given, the last four
words only if the
traceline is for method routine statements (for a detailed discussion
please see today's
posting entitled "Draft: documentation for multithreaded trace prefix
(mtPrefix)"). The
square brackets are part of mtPrefix to make parsing easy and as such
also writing analysis
programs of mtPrefix traces, if need be.
* instead of sending the trace line (a string at the moment) in
"Activity::traceOutput(...)"
create and send the traceObject that contains among other things the
traceline entry, hence
"stream->sendMessage(GlobalNames::LINEOUT, traceObject, result);"
* a Rexx programmer who wants to define the mtPrefix value on his own will be
able to do so by:
o creating an own class that
+ caches .traceOutput~current in its constructor from the time where
the monitored object
gets replaced by an instance of this class (for this example using
the attribute named
cachedTraceOutput)
+ implements a method LINEOUT to intercept the argument
# if the argument is not a TraceObject (it may have been already
processed or changed)
then pass on the argument unchanged, e.g. with
FORWARD TO (cachedTraceOutput)
# if the argument is a TraceObject then create the desired
mtPrefix taking advantage
of the information stored in the TraceObject (a StringTable),
maybe including the
traceline and forward the result to the attribute
cachedTraceOutput, e.g. in the
case of a string in a variable named editedTraceString with
FORWARD TO (cachedTraceOutput) ARRAY (editedTraceString)
As a result:
* tracing remains unchanged by default,
* adding mtPrefix is easy by either
o setting the TraceObject's class attribute mtPrefix to .true, */or
/*
o defining an own class to format the traceline any way the programmer
sees as helpful as
described above
* no need for adding a new function to control mtPrefix , no need to change
anything in the TRACE
keyword statement nor in the TRACE() BIF (the language remains small)
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
