Throttle errors coming from multiple threads

[luismbo]

It would be nice if the SLIME debugger could (optionally?) throttle multiple simultaneous errors coming from different threads.

Some discussion: http://thread.gmane.org/gmane.lisp.slime.devel/11401

[joaotavora]

I think common lisp's *debugger-hook* already gives the user that flexibility. Adding this to SLIME would be bloat, in my opinion. However a contrib is fine.

[luismbo]

Not yet sure it'd be bloat. If you spawn even as little as, say, 10 threads and they all invoke the debugger, your Emacs will be quite spammed with SLDB buffers. That doesn't seem to be very resilient default behavior. But maybe the onus is on the multi-threading framework to avoid situations like that, I'm not sure.

[joaotavora]

Maybe in that case you don't want to enable the existing lisp-side customization option SWANK:*GLOBAL-DEBUGGER* in your ~/.swank.lisp.

Maybe in that case you want to put something in your *CL:*DEBUGGER-HOOK* that understands the peculiarities and priorities of your program's multi-threading logic and decides if it calls the SWANK:SWANK-DEBUGGER-HOOK, which enables interactivity, or call some other non-interactive debugger, which perhaps dumps the stack trace somewhere and invokes an "abort" restart,

[luismbo]

Right, but as multithreaded programming becomes more and more common, perhaps SLIME should have a default behaviour that is saner than popping large amounts of SLDB buffers.

[joaotavora]

OK, if we're talking about sane default behaviour. Do you have a reasonable heuristic for that default behaviour? Don't allow more than N=3? outstanding errors at a time? Anything more complicated is better deferred to CL:*DEBUGGER-HOOK* or a specialized contrib. It doesn't even need to be slime-specific, though, a regular quicklisp package called "cl-multisanity" or something would be more useful across other IDE's that also popup errors.

[joaotavora]

Maybe "trivial-sanity" as you explained the other day...

[luismbo]

I think N might be either 1 or a parameter. SLIME's thread list can display which threads have pending errors, and you can debug any pending error you'd like. Maybe the SLDB buffer can also display how many errors are pending.

Not yet sure whether picking a restart in a given SLDB buffer should make the next pending error pop. What do you think?

[joaotavora]

What do you think?

I don't know. It's precisely adding this kind of logic to SLDB that I think would bloat it unnecessarily. It's quite huge already. There can be other cleanups, but still...

Anyway you say the SLIME thread list can already debug pending errors on demand, right? If so, I really think this is a case of advising users not to set SWANK:*GLOBAL-DEBUGGER* and be done with it.

Have you given any thought to creating a non-slime package that does manages these hooks?

[luismbo]

On Fri, Mar 7, 2014 at 3:47 PM, João Távora notifications@github.comwrote:

Anyway you say the SLIME thread list can already debug pending errors on
demand, right? If so, I really think this is a case of advising users not
to set SWANK:GLOBAL-DEBUGGER and be done with it.

No, AFAIK there is no concept of pending errors in SLIME thread list. I'm
proposing adding that.

Have you given any thought to creating a non-slime package that does

manages these hooks?

A little bit, but I couldn't figure out how a non-SLIME package fits the
proposal I suggested.

Luís

[joaotavora]

A little bit, but I couldn't figure out how a non-SLIME package fits the
proposal I suggested.

Obviously it doesn't fit your proposal. But it solves your problem :-)

The idea is providing a function that either globally/dynamically (via a macro) organizes any existing debugger-hook and install itself as the global/dynamic debugger hook. The package would provide a number of debugger managing algorithms...

But this concept of "pending errors" is quite amazing. Good luck.

[luismbo]

On Fri, Mar 7, 2014 at 4:58 PM, João Távora notifications@github.comwrote:

The idea is providing a function that either globally/dynamically (via a
macro) organizes any existing debugger-hook and install itself as the
global/dynamic debugger hook. The package would provide a number of
debugger managing algorithms...

Well, I'll try and prototype my proposal and see if it can be generalized
(and if it's worthwhile to do so) into such a thing.