My usual jbreak invocation (haven't tried on j904 yet) is to invoke it 2-5 times, because there is rarely an immediate response from J. I have no idea whether the extra invocations actually help, other than bashing the command has no competing use for my time, in those moments.
> If the user issues a second break before the ATTN has been noticed, it will force immediate termination of all tasks with the 'break' error. You're suggesting that a single jbreak might preserve more information to inspect. I'm not sure if this is current single threaded behaviour, and a 2nd jbreak press, can indeed achieve quicker break by losing the necessary coherence with the "softer" error of a single jbreak. As to, unrelated, your general release statement was to "work on a mutex/locking J enhancement primitives." : There has been a lot of recent work, by you, to make in-placed code for efficiency. It would certainly benefit threaded code as well. From a user perspective, if there was just an internal locking mechanism that made =: =. "atomic" such that read/write accesses were blocked until the assignments were complete, then there is nothing the user is forced to consider in order to safely read/write variables. Reading threads being automatically blocked until =: completes, or inplace + =: operation completes. With that said, my kv implementation could be structured with internal threading benefits. A global variable or object reference being explicity assigned to a thread (such that no copying is needed when accessing/communicating with that variable/object, ie. thread already knows its, potentially large, internal data, and if that global/object is y, then only the function and x needs to be sent to the thread, provide greater system throughput, even if it means queueing commands/read/write access to a thread. This "thread owns a global/object" functionality would reduce the need for alternate zeromq control of "datastructures" instead of the benefits of just t. 'myglobalvar'. So instead of users manually locking variables, locking being automagical would be a user benefit. One alterative interpretations of of f t. 'G' would be G =: [x] f t. '' G. ie. an implied y from conjunction. A definition of a perfect function is one that can be fed as (u^:) such that the result is of compatible shape for reapplication of u, and so the result is a good candidate for replacing the variable containing y. There are many f s, and an encouragement to design f s such that that f t. 'G' would be useful to J programmers, and unlike my previous suggestion, instead of allocating G to a specific thread, it would just provide enough info to lock reads from other threads until the operation completes. On Thursday, April 14, 2022, 12:18:48 p.m. EDT, Henry Rich <[email protected]> wrote: The next beta will support jbreak in multiple threads, as follows: Recall that running jbreak once raises the ATTN condition. This is a gentle tap on the shoulder, asking JE to stop at the start of a new sentence. A thread that is stopped by ATTN can be restarted reliably. Running jbreak a second time raises the BREAK condition. This poleaxes JE into immediate insensibility, possibly in the middle of a sentence, and you are on your own to decide whether continuation is feasible. When debug suspension is disabled, a single jbreak will be detected by the first task that starts a sentence. That task will fail with an 'attention interrupt' error. The system will then automatically simulate a second jbreak to force quick termination of all other tasks with the 'break' error. If the user issues a second break before the ATTN has been noticed, it will force immediate termination of all tasks with the 'break' error. When debug suspension is enabled, a single jbreak will be noticed by all tasks when they start a sentence or when they wait for a pyx after another task has noticed the break. After all tasks have noticed the break, the system enters debug suspension. The first thread that noticed the break will be the debug thread and the others will be dormant until execution is resumed. If the user issues a second break before the ATTN has been noticed, all tasks will interrupt their sentences as soon as possible to enter debug suspension with the 'break' error. You are on your own to decide whether continuation is feasible. There is no automatic detection of deadlock. double-jbreak is the only way out of deadlock/livelock. Henry Rich -- 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
