GNU bug report logs - #63311
30.0.50; [PATCH] smtpmail-send-it split

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 63311 <at> debbugs.gnu.org
Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split
Date: Mon, 06 Nov 2023 18:28:41 +0200

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: 63311 <at> debbugs.gnu.org
> Date: Mon, 06 Nov 2023 16:56:33 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Yes but how would I do that.  My idea was to left much code unmodified
> >> (with all 'error' calls in case something goes wrong).  But how the
> >> 'main-thread' could fetch these errors.
> >
> > Using thread-last-error, or at least that's what I had in mind.
> 
> It seems that 'thread-last-error' is global for all threads of Emacs so
> I don't it would work.  Doesn't a thread record its error status and
> message?

Sorry, I don't understand what exactly you are asking and what you are
saying.

Yes, thread-last-error accesses a global storage, but I fail to see
how this is a problem: if the main thread fetches the error in a
timely fashion, it should still work.  And if, for some reason, this
is not good enough, we could come up with a more fine-grained
mechanism.  But first I'd like to see a description of a real problem
with the existing mechanism: after all, it isn't expected that every
single thread you launch will die due to an error, right?  So the
situation where a thread dies and we need to access its error should
be relatively rare, and a global resource could still be adequate.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.