1. what about backtrace/step/.. in other threads? GDB supports it (info
thread, thread n, etc.)
2. what if two threads both try to start debugging at the same time?
Maybe there should be a dedicated debugging thread, instead of hijacking
an existing one.
On Thu, 14 Apr 2022, Henry Rich wrote:
I wouldn't test this on beta-b. Next beta has a good chance.
The plan is that when one processor decides to go into debug suspension,
it notifies all the others. One by one the tasks stop running, each
calling a synchronizing routine. When all the tasks agree that they are
in a stopped state, the first one becomes the debug task. Only the
debug task runs the latent expression and prompts. It can look into
other threads' private namespaces, since they all share a memory space.
When you resume execution all the tasks wake up. What error state they
wake up up is a detail to be worked out.
The mechanism for coordinating the threads' stopping is tested, because
it is used to resize the symbol table. Its application to debug should
be straightforward and I have coded it, but not tested yet.
Henry Rich
On 4/14/2022 8:59 PM, Raul Miller wrote:
On Thu, Apr 14, 2022 at 3:28 PM I wrote:
Conceptually, the debug thread mechanism could be hijacked as a
synchronization mechanism.
At least in j904 beta b, this approach has a severe practical problem.
Here's an illustration of the underlying mechanics:
NB. ensure we have some threads
0&T.@'' each i.0>.4-1 T.''
NB. use a couple threads
{{6!:3 y if.1 do.echo y end.}} t.''"0] 10 11
NB. sync
13!:0]1
13!:15'joinImplementation 0'
joinImplementation=: {{
NB. synchronization mechanism would go here
echo '-------------'
echo '1 ',":1 T.''
echo '2 ',":2 T.''
echo '3 ',":3 T.''
echo 13!:1''
echo '-------------'
13!:5''
}}
test=: {{
echo 'a'
assert. 0
echo 'b'
}}
test''
When I run this script, I expected my debug latent expression to run
immediately. Instead, it does not run until all tasks have completed
their work. This behavior was not intended, if I understood correctly.
Additionally, the 13!:5'' does not resume execution -- I can work
around this by replacing that line with 9!:27'13!:5'''''[9!:29]1 so
that's less of an issue for now.
That said, my vision here was to define a 'sync' adverb which takes a
y argument, stores it in a task specific variable, and then uses
assert. to enter the debug sentence. The debug sentence would
recognize that 'sync' was used and would pick up the thread's y value
and execute u against it. I have not figured out how to read the debug
thread number, however, so I would have to inject that information
into the stack trace, and pull it out of the 13!:13'' result.
But... as you can see... this would be rather slow in beta b.
FYI,
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
