Re: User interaction from multiple threads

[Eli Zaretskii <eliz@gnu.org>]

> From: hw <hw@adminart.net>
> Cc: psainty@orcon.net.nz,  gazally@runbox.com,  rms@gnu.org,  emacs-devel-bounces+psainty=orcon.net.nz@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 02 Sep 2018 18:37:15 +0200
> 
> >> Would you say that when a user is writing a function that does some
> >> string replacements within texts that are usually between 16 and
> >> 64kB in size should use multiple threads to replace different
> >> strings or not?
> >
> > Could be, if the code is written to yield from time to time.
> 
> Does that mean functions like (replace-string) should now be rewritten
> to yield time?

If you want such functions to yield, yes, you need to insert a call to
some yielding API from time to time.

> Or are they already written like that?

No.

> Or does it mean someone writing a function should always write it so
> that it yields time, accepting that it might be slowed down?

Yes, if the function doesn't ask the user questions (in which case it
will yield automatically while it waits for response), like
query-replace.

> > It is advantageous if some of the threads call yielding APIs, since
> > then other threads could run while they are waiting.
> 
> Shouldn't threads that are just waiting yield time to others
> automatically?

They should and they do.  Calling yielding APIs doesn't mean the
programmer needs to inject stuff like thread-yield, it could mean use
of read-key-sequence or accept-process-output or sit-for, to name a
few.

> When I use Term::ReadKey in perl to read a key, my program can be
> waiting for a key to be pressed without using CPU time.  It does that
> automatically.

Emacs does that as well.