If two threads start debugging at the same time, one will win. Atomic
operations are used. (It's actually more complicated that that: one
thread may start debugging, while another thread needs to expand the
symbol table, a higher-priority requirement. The threads confer on
their priorities after they have all stopped, to see who should run.)
The 'debug thread' concept is actually a fiction. Once all the state
information has been flushed to memory, a 'thread' is really a state of
mind. Thread x can look at thread y's stuff, and even execute as thread
y, without hurting anything. The single-step operations should work in
any thread. (T. n) is the equivalent of gdb's 'thread n'.
Henry Rich
On 4/14/2022 9:19 PM, Elijah Stone wrote:
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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
