emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Shrinking the C core


From: Arthur Miller
Subject: Re: Shrinking the C core
Date: Tue, 29 Aug 2023 04:36:24 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> However, my thesis was not that it is impossible to do in Emacs, but
>> that there is a lisp machine that already has figured out that work.
>
> As is already customary from you

I'll take that one as english skill; and I really mean it in this case,
since the discussion further suggest that.

> Lisp interpreter within different lwps with the task of making it safe
> to do so, should code running in that interpreter attempt to leverage
> Emacs primitives.

I am not sure what you are trying to tell here.

> True, the first problem has already been solved by eminent Lisp
> implementations.  But we have almost solved it as well.  And if two

Well, I am very glad if you did. Honestly.

>                                                          And if two
> threads modify a buffer simultaneously, leaving PT and PT_BYTE out of
> accord, Emacs will crash regardless of whose threads it's using.

Is it possible to let one thread at a time modify the buffer (lock the
buffer) and use some notification system to tell other threads they
should update their view of buffer state when they resume, or perhaps
some "main thread" can update the buffer state a thread sees before it
is resumed?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]