Coming back to this RFE from 17 months ago which I would like to add to trunk. Without it one can
hardly use TRACE for debugging multithreaded programs in a Rexx-like, i.e. easy manner.
Currently having tried to incorporate the feedback about too many whitespaces between the new
columns (Rexx interpreter instance number, Thread number, Activity number, reserved object pool).
There was another idea about making this concurrency/multihreaded trace available without a need to
define an environment variable RXTRACE_CONCURRENCY before starting a Rexx program. This post is
about ideas of how to activate and deactivate concurrent tracing at runtime (either via the TRACE
keyword instruction or the TRACE()-BIF) in a manner that is intuitive and easy to remember.
One possibility would be to introduce new alphabetic options, this time with two letters by
prepending the letter 'M' (for multithreaded as the letter c is already used for tracing commands
and may therefore be irritating) to the existing alphabetic characters, hence defining the following
semantics:
*Trace**
* *Option, turn off MT**
* *Option, turn on MT**
*
All
A
MA
Command
C
MC
Error
E
ME
Failure
F
MF
Intermediates
I
MI
Labels
L
ML
Normal
N
MN
Off
O
-
Results
R
MR
This would have the benefit that anytime it becomes possible to turn on and to turn off
multithreaded/concurrent tracing at runtime.
What do you think?
---rony
P.S.: The "fallback" would be to just add it as is, i.e. using the environment variable
RXTRACE_CONCURRENCY, making the multithreaded/concurrent tracing a global option that needs to be
set before running a Rexx program.
On 05.09.2021 14:12, Rony G. Flatscher wrote:
Almost a week ago Jean Louis Faucher registered feature request "794 Concurrency
request", cf.
<https://sourceforge.net/p/oorexx/feature-requests/794/> together with a patch
that implements the
feature request. So far there have been no comments, hence "requesting for comments
(RFC)" here as
it may be the case that the RFE has been overlooked.
---
IMHO this RFE is incredible helpful for debugging multi-threaded Rexx programs
and for understanding
how ooRexx dispatches multithreaded code.
The way Jean Louis devised the implementation has practically no impact on the
interpreter (unless
one defines an environment variable "RXTRACE_CONCURRENCY=on" modelled after the
existing
"RXTRACE=ON" environment variable in which case helpful information gets
generated for prefixing
each trace output statement) makes it easy even for beginners (= students) to
get insight and
understand how ooRexx executes multithreaded programs. Some problems rooted in
multithreaded Rexx
code can be quickly located, understood and resolved with this feature.
Having tested this concurrency trace feature with the most challenging JavaFX
ooRexx programs I have
been really impressed with the results. Using the ooRexx program
"samples/tracer.rex" (included in
the patch) to render the massive concurrency trace output of some JavaFX ooRexx
programs to csv and
importing the concurrency trace into a spreadsheet (e.g. Excel) makes it
possible to analyze such
massive concurrency traces in every possible detail using the spreadsheet
features (e.g. filtering
for a specific ooRexx interpreter instance or specific threads, pivots and the
like). Therefore I
uploaded one such test to this RFE such that one can directly get at the
massive concurrency trace,
the csv file created by "tracer.rex" from it and an Excel spreadsheet which was
used to import the
generated csv file. (I wished this feature had been available when devising
some of the BSF4ooRexx
JavaFX samples, which would have saved me literally weeks of debugging!)
The patch implementing RFE 794 makes it really easy for ooRexx programmers to
understand and to
debug multithreaded ooRexx programs, saving them a *lot* of time trying to
understand what happens,
how concurrent statements get executed by the interpreter(s) and locating
coding errors!
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
