I believe that jbreak's error message includes the code where it stopped. I
like very much how single threaded error messages include a tabbed layout of
the code that helps pinpoint the exact source of the error.
An advantage of functional code (defined loosely as global variable updates
being the result of functions, as opposed to modifications being made inside
functions) is that interruption of the function interrupts assignment of the
result. In non-functional code, reloading a script that assigns initial values
to globals, solves an incoherent state situation caused by an interupt.
Sure, being able to inspect variables after a jbreak can be useful. But
there's only 2 reasons to call jbreak. An infinite loop bug, or "it's just
taking longer than I wanted to wait". The line of code where jbreak occurred
tells you both problems. The 2nd reason for jbreak, if the code is fine, is
that the input was too large/"permutationy"
If I have to invoke jbreak, I always want to fix code or avoid calling with the
same function arguments. (jbreak is god's way of teaching me combinatorics).
If a thread were interrupted (only one function per thread) due to a jbreak
need, I'd first want to see how it behaves without t.
this code will hang J under the last variation.
0 T. ''
2
t =: t.''
G =: 0
(3 : '-:`+:@.G y'"0 t {:@>@[ 3 : 'G =: -. G'"0 t) i.11 NB. fine because right
thread finishes before left thread starts.
5
(-:`+:@.G t {:@>@[ 3 : 'G =: -. G'"0 t) i.1111 NB. when initial G value is 1,
bound in left function as constant
2220
(3 : '-:`+:@.G y'"0 t {:@>@[ 3 : 'G =: -. G'"0 t) i.1111 NB. J hang. jbreak no
help. Long enough to still run right function when left thread starts.
My only expectation here would be for god to teach me about terrible
multithreading code in a gentler way than a hang. I'm not sure that it should
be a priority to make that work with some kind of interthread-coherence
methods. If you want random data based on the state of other threads, then you
can write a sequential-code random function. Even if you could interrupt the
left thread, inspecting G while right thread is running would get a snapshot of
G that is immediately out of date. If all threads were suspended, the race
dynamics on resume would be different than if no suspension occurred.
That said, if the left function were run with t. 'G', where n=. 'space
delimited list of variables to wait until a synchronized read can be performed'
then that could permit terrible code, without affecting performance of
non-terrible code.
On Wednesday, April 13, 2022, 10:32:35 a.m. EDT, Henry Rich
<[email protected]> wrote:
We need some rules for designing by committee. First rule is that
nothing is agreed until it comes with a spec for action. It is true
that you (Pascal) suggested having a T.-function to shut down a thread,
and Raul & I agreed. But that's merely an agreement of interest. It's
not a commitment to action. To begin with, we have to define what
'shutdown' means. Does it leave the execution stack for inspection?
Does it delete global names & values? Does the action depend on whether
debug is running?
I think there should be a difference between interrupting a thread and
killing or shutting it down. jbreak normally signals error, which
terminates everything on the execution stack unless debug is enabled.
Let's call that 'interrupting' the thread. The proposal is that jbreak
should interrupt all threads.
We must consider how violently to interrupt the threads. Stopping a
sentence in the middle of execution is risky: the sentence can't be
resumed in the middle, and it may be impossible to continue execution.
The gentler action is to wait for a sentence to finish. That's what
jbreak does.
Should there be a jbreak for an individual thread? Should we allow for
resuming individual threads?
The JE design has a feature called the 'system lock', which brings all
threads to a stopping place before continuing execution in a single
thread. That is how debug is entered. Perhaps jbreak should interrupt
thread 0, which will enter debug if that is enabled or signal error in
the other threads if debug is not enabled?
Just ideas.
Henry Rich
On 4/13/2022 10:09 AM, 'Pascal Jasmin' via Beta wrote:
> I think we agreed that there should be an x T. threadid function that
> shutsdown a thread.
>
> jbreak.bat should shut down all non idle threads "too".
>
>
>
>
>
>
> On Wednesday, April 13, 2022, 09:57:24 a.m. EDT, Henry Rich
> <[email protected]> wrote:
>
>
>
>
>
> Responding to jbreak still needs to be designed. Currently it will
> interrupt only the first thread that sees it. That seems wrong. How
> should it work?
>
> Don't draw too many conclusions from the behavior of beta-a in edge cases.
>
> Henry Rich
>
> On 4/13/2022 9:42 AM, Raul Miller wrote:
>> On Wed, Apr 13, 2022 at 8:46 AM Henry Rich <[email protected]> wrote:
>>> I don't think this is a deadlock. It's just an infinite recursion, made
>>> painfully slow by the delay.
>> In my case, it was the script I had sent you that was hanging, and was
>> not (after a few seconds, or a few hours) interruptible.
>>
>> Shouldn't it at least be interruptible?
>>
>> Thanks,
>>
>>
>> --
>> Raul
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
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
