Re: User interaction from multiple threads

[Phil Sainty]

On 2018-08-24 20:51, Eli Zaretskii wrote:
> I don't expect anyone to remember which name corresponds to what job
> that is running in the background, when there are enough of them.

I concur that this would sometimes happen.  Perhaps commonly.  I also
think that other times it would be entirely apparent to the user, and
therefore that facilitating the latter is significantly better than
showing nothing at all on the basis of the former.


> That name will have to come from some Lisp written by the same
> programmers whom you don't trust to provide self-explanatory prompts,

No so -- the programmer who wrote the (new) threaded code which has
triggered the prompt is not necessarily the same programmer who wrote
the (old) prompt code which has been triggered (perhaps by some
unexpected side-effect) by the new code.

Hopefully most prompts *will* still end up being clear in these
situations, but to me it doesn't seem sensible to simply trust that
what is self-explanatory in a single-threaded situation will remain so
in a multi-threaded situation.


> If the Lisp program that starts a thread doesn't provide a name,
> Emacs will identify it as something like #<thread 0x01a2d468>, which
> is not helpful in the situations we are discussing.

Personally I would still vote for display that over displaying
nothing.


> And even if we do require each thread to have a name, what
> guarantees do we have that the name will be more informative than
> the prompts about which you were worried?

Obviously "guarantee" is a strong term, but the thread name would
(or at least *could*) provide a context which is entirely independent
of the prompt.  As I understand it, the prompt code may have no
particular connection to the multi-threaded library which caused it
to appear, and therefore have no way of phrasing itself in a way
which makes that connection apparent to the user.


-Phil