Yes, opening a pyx-in-error signals error as usual and if suspension is
enabled, the system (all threads) will go into suspension.
If we detected deadlock, we could treat that as completing the
deadlocked pyxes with an error result. I'm not sure how easy it is to
find them.
Also, you can have a 'livelock', where the tasks are waiting for each
other but not through pyxes (through global names).
Perhaps the best thing is to let the usual break into the system if they
suspect a deadlock. It seems unlikely that a user will create a
deadlock accidentally - the cases we have seen would give errors if run
on a single-threaded system.
Henry Rich
On 4/13/2022 6:15 PM, Raul Miller wrote:
On Wed, Apr 13, 2022 at 6:03 PM Henry Rich <[email protected]> wrote:
OK, I see. The expression is an error without the assignment to a, but
the assignment creates a race condition that can result in a self-reference.
I guess it is possible to detect the situation when all the non-idle
threads are waiting for a pyx, and halt everything then. Like with
jbreak, what state would the threads be in?
Given that opening a pyx can result in an error, I think opening a pyx
should possibly result in a suspension (if suspension is enabled).
Also, deadlock should be an error.
Does this make sense from your perspective?
Thanks,
--
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
