bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#63311: 30.0.50; [PATCH] smtpmail-send-it split


From: Eli Zaretskii
Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split
Date: Mon, 06 Nov 2023 18:28:41 +0200

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: 63311@debbugs.gnu.org
> Date: Mon, 06 Nov 2023 16:56:33 +0100
> 
> Eli Zaretskii <eliz@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]