Re: [External] : Re: Would you say this information window is well designed?

[Eli Zaretskii <eliz@gnu.org>]

> Cc: drew.adams@oracle.com, stefankangas@gmail.com, larsi@gnus.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 27 Feb 2021 23:44:18 +0200
> 
> > thread-yield runs in the context of the thread that yields.  You make
> > it sound like there's some entity other than the involved threads
> > which runs thread-yield, but that's not what happens.
> 
> It was also my impression that the threading facility in Emacs is 
> incomplete.

Nothing in Emacs is ever complete.

> For one thing, error handling is very low-level (saving only the last 
> error looks like a straight translation from C).

Patches welcome.  The original version didn't provide even that
rudimentary error handling.

> Another: there is no 'thread-resume' which some came to expect from 
> other languages.

IMO, thread-resume makes no sense when only one thread can run at a
time.

We could instead add an optional argument to thread-yield, with the
effect that the calling thread would yield to the thread specified by
the argument.

> But it seems we can substitute with condition-wait (in the worker 
> thread) + condition-notify (in an idle timer which it would create 
> before waiting). That should help suspend-resume the worker thread on a 
> regular basis, all the while giving the main thread the time to do its 
> thing.

I encourage you (and everyone else) to try to come up with a real-life
application that uses this paradigm, and see if it works well.  The
original design didn't intend for this to become the main paradigm,
but that doesn't mean it cannot work well.

> Either way, I don't think this can solve the original issue. Having a 
> link appear only some time after a Help buffer is shown is not a great 
> experience either: blinking elements are a visual nuisance. So if we 
> could pre-index the manual for symbols, that would be preferable.

I tend to agree.