wanted: sb-thread:make-thread should remember call-site

[Tobias C. Rittweiler]

I do not know whether this is possible, but I'd _much_ appreciate if MAKE-THREAD
would store information about the frame belonging to its call-site somehow so it
appears in backtraces from errors in the new thread.

[Nikodemus Siivola (nikodemus)]

If you mean have the source-location for the MAKE-THREAD call site, that could be done: add a source-location slot to the lisp-side thread object, and have a compiler-macro for MAKE=THREAD pass in the source location.

[Tobias C. Rittweiler (tcr)]

Nikodemus Siivola <email address hidden> writes:

> If you mean have the source-location for the MAKE-THREAD call site, that
> could be done: add a source-location slot to the lisp-side thread
> object, and have a compiler-macro for MAKE=THREAD pass in the source
> location.

Unfortunately, I don't think that will be enough as
SB-THREAD:MAKE-THREAD is often invoked from within some wrapper
function. So ideally, it should store a tiny portion (like 3-5 frame?)
of the stack, or something like that. I don't have a clue about the
technical aspects involved.

  -T.

--
Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht
und ist - aktuelle Virenscanner vorausgesetzt - sauber.
Freebits E-Mail Virus Scanner

[Nikodemus Siivola (nikodemus)]

2009/11/20 Tobias C. Rittweiler <email address hidden>:

> Unfortunately, I don't think that will be enough as
> SB-THREAD:MAKE-THREAD is often invoked from within some wrapper
> function. So ideally, it should store a tiny portion (like 3-5 frame?)
> of the stack, or something like that. I don't have a clue about the
> technical aspects involved.

Depending on the wrapper depth, there is no way to guarantee sufficient information, and copying bits of the callers stack for debugging purposes seems both messy and brittle.

Source-location is fine. Stack sounds crazy to me. :)

I would rather put the onus on the people creating threads to provide sufficient contextual information: THREAD-NAME is already there, and we can add something like THREAD-PLIST if there is call for it, or make threads subclassable ala Franz -- anything rather than capturing bits of the parents stack.

(I can be easily persuaded otherwise, but only by someone willing to implement whatever nifty idea they have...)

Cheers,

 -- Nikodemus

[Attila Lendvai (attila-lendvai)]

re THREAD-PLIST: isn't that easily implementable using a special that is automatically rebound in new threads? iow, redundant? well, debugging tools like Slime could show it, which would be useful, but that's fixing the dev env's lack of extensibility at the wrong position, imho.

this would be trivial to implement if there was a *new-thread-default-special-bindings*, containing eval'd forms or funcall'd closures that return a list of specials and their values. (although there's prior art on this, and i didn't spend enough time considering what is The Right Way(tm) to implement them...)

just some 0.02...

[Gábor Melis (melisgl)]

On Friday 20 November 2009, Attila Lendvai wrote:
> re THREAD-PLIST: isn't that easily implementable using a special that
> is automatically rebound in new threads? iow, redundant? well,
> debugging tools like Slime could show it, which would be useful, but
> that's fixing the dev env's lack of extensibility at the wrong
> position, imho.

I cringe at the thought of XXX-PLIST, because there is no end to the
list of classes that should have it. IMHO annotations like this are
better placed in weak keyed hash tables.

> this would be trivial to implement if there was a
> *new-thread-default- special-bindings*, containing eval'd forms or
> funcall'd closures that return a list of specials and their values.
> (although there's prior art on this, and i didn't spend enough time
> considering what is The Right Way(tm) to implement them...)
>
> just some 0.02...
>

See https://bugs.launchpad.net/sbcl/+bug/310204. Interested parties may
want to read the linked gmane thread for some discussion.

Cheers, Gabor

[Nikodemus Siivola (nikodemus)]

2009/11/20 Gábor Melis <email address hidden>:

> I cringe at the thought of XXX-PLIST, because there is no end to the
> list of classes that should have it. IMHO annotations like this are
> better placed in weak keyed hash tables.

I don't particularly disagree, and THREAD-PLIST is certainly not on my TODO.

(...though if we added a plist slot to closures, functions, instances, and funcallable instances we would be pretty much covered. Well, maybe vectors and array-headers too. :P)

So: source location of the call-site doesn't appear to be what is needed, and unless someone wants to copy MAKE-THREAD's caller's frames, I think this is going to be WONTFIX after all.

[Douglas Katzman (dougk)]

Thread-name is there for a reason, and any discussion of thread-specific special bindings has nothing to do with what this bug was asking for. Definitely WONTFIX.