Re: Emacs design and architecture. How about copy-on-write?

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> If we are talking about an Emacs where programs meant for threads will
> need to be written from scratch using special protocols and
> primitives, then all bets are off, and I'm not sure everything we
> discussed at such a great length lately is at all useful or even
> relevant.  The idea was to allow existing Lisp programs run from
> threads with little or no changes, by just starting a thread which
> runs a function that is already written and debugged when running in
> the (single) main thread.  If this is not what you have in mind, try
> first to see if users will be likely to switch to such an Emacs or use
> such threads, when they know they will need to drop everything and
> start from scratch.  Who will want to write a "multithreaded Gnus"
> starting from scratch?

Let me clarify.
I am not saying that existing Elisp code should not be allowed to run
from threads. It should.

However, I think that it can be acceptable to leave certain things
interlocked - if async thread is querying, for example, user input or
redisplay, acquire a global (or input/redisplay) lock, and run that
portion of the thread synchronously.

That way, we can still allow useful Elisp to run concurrently, when
running CPU-intensive computation. These CPU-intensive parts will need
to be rewritten with concurrency in mind. But only parts - the rest of
the code could be left unchanged without breaking things.

Later, we may also figure out more tricky parts related to async
input/redisplay. 

>> Maybe. But reducing the overall waiting time at the cost of not seeing
>> the progress is an OK compromise, IMHO.
>
> If the time is more than, say, a second or two, then no, such a
> compromise will not be liked.  At least for Grep-style searches and
> other compile-like commands.

Sure. I am talking about M-x grep on large projects, when it takes tens
of seconds to finish. Same for org-agenda - it is not uncommon when
org-agenda searches last for a minute when search criteria is complex.

>> What about addressing the existing problems with cooperating Lisp
>> threads then?
>
> What about it?  Patches are welcome, of course.  Last time we
> discussed these issues, we were unable to find good ideas for solving
> them.  Maybe we should try discussing them again.

Are you referring to input discussion? Something else? I think that it
could be useful to document problems to be solved in etc/TODO.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>