Years ago jconsole and the gui interface were in a different thread from je. I never really understood why they were moved into the same thread with je. Maybe they should be moved back to a different thread. Granted, this doesn't solve the problem of which thread or threads need to break, but it should make it easier to implement whatever is decided.
On Wed, Apr 13, 2022 at 8:32 AM 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
