Don, jconsole was never in a separate task or thread from JE. The windows/java front ends (j602) were in separate tasks/threads and things like break were a bit simpler.
I'm hoping one thing coming out of the new T. facilities will be a better way to handle things like break and resource limits. There is enormous potential here and it will keep us busy. First we need to learn to walk with T. . On Wed, Apr 13, 2022 at 10:46 AM Don Guinn <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
