GNU bug report logs - #32502
27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs

Previous Next

Full log

View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gemini Lasswell <gazally <at> runbox.com>, 32502 <at> debbugs.gnu.org
Subject: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs
Date: Thu, 30 Aug 2018 09:19:04 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Another thought is that the thread-last-error function is currently not
>> very useful, because its caller has no way to tell which thread had the
>> error, and if more than one thread has an error, only the most recent is
>> saved.  An improvement would be to give it an optional argument, a
>> thread, and have it return the error that made that thread inactive, if
>> there was one.  (This could probably replace the recently added cleanup
>> argument.)
>
> We could indeed make the error bookkeeping more sphisticated.
>
>> Then asynchronous find-file could make a list of the threads it starts,
>> and start either a timer or another thread to periodically check that list
>> of threads, look for those which recently became inactive and report any
>> errors with 'message', or wait until all threads are done and print a
>> summary of successes and failures.
>
> I don't think this will work, at least not literally as described,
> because (1) running timers in multithreaded environment is tricky --
> you don't know which thread will run it, but more often that not it
> will be the main thread; and (2) only one thread runs at any given
> time, so making a thread that will periodically do something is not
> simple, as there's no guarantee it will indeed run with the requested
> periodicity.

Instead of a timer, the asynchronous find-file could check for errors of
the finished thread(s). A good point might be, when thread-join delivers
the result(s).

It was said earlier already (I believe), but I repeat it: thread-join
should not only return the result, but should also propagate signals the
thread has been trapped. It would be the responsibility of the calling
code to ignore this information, or to propagate.

Best regards, Michael.

Previous Next

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