[Top][All Lists]

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

Re: Concurrency via isolated process/thread

From: Ihor Radchenko
Subject: Re: Concurrency via isolated process/thread
Date: Mon, 24 Jul 2023 13:15:55 +0000

Eli Zaretskii <eliz@gnu.org> writes:

>> The basic idea is to have
>> #define PT (current_thread->m_pt + 0)
>> #define PT_BYTE (current_thread->m_pt_byte + 0)
> Point is the attribute of a buffer.  The current definition of PT,
> viz.:
>   #define PT (current_buffer->pt + 0)
> automagically makes PT refer to the current buffer, so the code only
> needs to change current_buffer to have PT set correctly.
> By contrast, you propose to have one value of point per thread, which
> means a thread that switches buffers will have to manually change all
> of these values, one by one.  Why is that a good idea?

Switching buffer already involves juggling with pt_marker_ in
record_buffer_markers and fetch_buffer_markers.

So, I do not see much problem here.

> And what about C code which copies/moves text between two buffers?
> For example, some primitives in coding.c can decode text from one
> buffer while writing the decoded text into another.

They still use set_buffer_internal.

There are certain cases when the code needs to fetch buffer point from a
buffer that is not current, but I did not yet look into them closely
before asking if the whole idea is going to be acceptable. (Roughly, I plan
to use thread point history or fallback to default point position as in
buffer constructor).

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>

reply via email to

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