[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Concurrency via isolated process/thread
From: |
Eli Zaretskii |
Subject: |
Re: Concurrency via isolated process/thread |
Date: |
Mon, 24 Jul 2023 15:50:34 +0300 |
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Mon, 24 Jul 2023 10:09:50 +0000
>
> 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?
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.
> Basically, use thread object slot instead of buffer object slot to store
> point and restriction. This will not cause any performance degradation
> and allow multiple points in the same buffer.
>
> What may be slightly slower is setting/getting points in other (not
> current) buffers.
> We will need to store point and restriction history for each thread.
> Searching this history will scale with the number of buffers that have
> been current previously during thread execution (though we may use hash
> table if necessary).
>
> However, accessing and changing point in buffer that is not current is
> not very common. AFAIU, it is done in (1) read operation when reading
> from stream represented by a buffer; (2) when switching buffers when we
> need to transfer current PT to history for current buffer and retrieve
> PT from history for the buffer that will become current.
Once again: please state the final goal, and please describe at least
in principle how these measures are steps toward that goal.
> I propose to remove buffer points completely and use thread points
> instead.
I don't think this could fly, because we must be able to copy text
from one buffer to another in a single thread, see above.
- Re: Concurrency via isolated process/thread, (continued)
- Re: Concurrency via isolated process/thread, Po Lu, 2023/07/17
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/24
- Re: Concurrency via isolated process/thread, Po Lu, 2023/07/24
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/24
- Re: Concurrency via isolated process/thread, Po Lu, 2023/07/24
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/24
- Re: Concurrency via isolated process/thread, Po Lu, 2023/07/24
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/24
- Re: Concurrency via isolated process/thread, Po Lu, 2023/07/24
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/25
- Re: Concurrency via isolated process/thread,
Eli Zaretskii <=
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/24
- Re: Concurrency via isolated process/thread, Eli Zaretskii, 2023/07/24
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/24
- Re: Concurrency via isolated process/thread, Eli Zaretskii, 2023/07/24
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/24
- Re: Concurrency via isolated process/thread, Eli Zaretskii, 2023/07/24
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/24
- Re: Concurrency via isolated process/thread, Eli Zaretskii, 2023/07/24
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/24
- Re: Concurrency via isolated process/thread, Po Lu, 2023/07/24