Re: Concurrency via isolated process/thread

[Po Lu <luangruo@yahoo.com>]

Ihor Radchenko <yantar92@posteo.net> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> 3. Current buffer, point position, and narrowing.
>>
>>    By current design, Emacs always have a single global current buffer,
>>    current point position, and narrowing state in that buffer.
>>    Even when we switch cooperative threads, a thread must update its
>>    thread->current_buffer to previous_thread->current_buffer; and update
>>    point and narrowing by calling set_buffer_internal_2.
>>
>>    Current design is incompatible with async threads - they must be able
>>    to have different buffers, points, and narrowing states current
>>    within each thread.
>>
>>    That's why I suggested to convert PT, BEGV, and ZV into
>>    thread-locals.
>
> Would it be acceptable to convert buffer PT, BEGV, and ZV into
> thread-local for current cooperative threads?
>
> I am thinking about:
>
> 1. Removing pt, pt_byte, begv, begv_byte, zv, zv_byte, pt_marker_,
>    begv_marker_, and zv_marker_ from buffer objects.
> 2. Adding pt/begv/zv to thread object.
> 3. Adding an alist linking buffers and past
>    pt/begv/zv positions visited by a given thread.
>
> This way, when a thread yields and later continues executing, its point
> and restriction will not be changed.

It may be possible to implement this with our current yielding system.

But how much do you want to slow down accesses to PT in the future, when
multiple threads will run simultaneously?  Operations that use and
modify PT are essentially the bread and butter of Emacs, and as a result
accesses to PT must be very fast.

In addition to that, we already have separate window and buffer points.
It would confound users even more to add a third kind of object with its
own point to the mix.