Re: Release plans

[Thomas Lord]

Thien-Thi Nguyen wrote:
> So no, i don't think the bottleneck would be the buffer access (for this
> design), because the subprocess does not really need to access the buffer.
> Changes to the buffer that have not yet hit the filesystem can be
> communicated by publishing some portion of `buffer-undo-list' (which is
> also relatively lightweight).
>   

So, the sub-process basically contains a text editor
in this design, albeit one without redisplay code and
with an unusual, limited command set.   That need for
redundant code to make this thing work helps to prove
that, indeed, the absence of dynamic loading (including
just shared memory regions for buffers) creates make-work
to work around it.

I'm also skeptical about the performance claims here.
A full update involves changing the buffer, print + system
calls to inform the sub-process, system calls + read to
get back the results of the parse updates, and then the
actual text property updates.     For interactive typing
that can probably keep up on a modern machine but
for other stuff it can easily be a performance bottleneck.
(Still, even if it is not, it's doing it "the hard way".)


>    and it can be very costly to pass that text to the subprocess and
>    then process the returned value (which may look like a list of text
>    properties to add to various parts of the text).
>
> Well...
>
>    A DLL could be significantly more efficient.  The difference can be as
>    large as "on-the-fly" vs "batch".
>
> ...i suppose i'll have to agree that all these "could be" scenarios are
> possible.  My view is that given the requirement of external symbol tables
> (and other state), the biggest win for both performance and maintainability
> is to go asynchronous.  If you want async from a subprocess, no worries,
> but if you want async in-process, you need to either design (and debug and
> maintain) "ethreads", or make Emacs play nice w/ pthreads or quickthreads
> or phase-of-the-moon-threads or whathaveyou.  Then, you need to make sure
> every visitor treats your program counter w/ the respect it deserves.
> That's a lot of thankless and brutish police work.
>   

That seems exaggerated.   A hook in the interact loop that locked
a shared mem buffer briefly while asking for updates from an
incremental parser / ide-helper doesn't seem like it would be all that
hard to get right.

-t