Re: User interaction from multiple threads

[hw <hw@adminart.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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: Sat, 01 Sep 2018 19:32:07 +0200
>> 
>> > There's very little overhead, but if you are interested in the
>> > details, I suggest to read thread.c.  It's not a lot of code, and the
>> > ideas are quite simple.
>> 
>> I wish I had at least 50 lifetimes so I could do more of what I would
>> like to do.
>
> Same here.
>
>> 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?  Or are they already written like that?  Will or did that
slow them down?

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

>> I would expect it to be slower because of the overhead unless multiple
>> threads could run at the same time.  Since they can't, what would be an
>> advantage of using multiple threads?
>
> 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?

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.