From: "Gerd Möllmann" <gerd.moellmann@gmail.com>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: Eli Zaretskii <eliz@gnu.org>,
eller.helmut@gmail.com, pipcet@protonmail.com,
emacs-devel@gnu.org
Subject: Re: MPS: a random backtrace while toying with gdb
Date: Tue, 02 Jul 2024 06:33:29 +0200 [thread overview]
Message-ID: <m2h6d8h0py.fsf@pro2.fritz.box> (raw)
In-Reply-To: <877ce4992g.fsf@localhost> (Ihor Radchenko's message of "Mon, 01 Jul 2024 20:00:23 +0000")
Ihor Radchenko <yantar92@posteo.net> writes:
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Ihor Radchenko <yantar92@posteo.net> writes:
>>
>>> Note that our SIGCHLD signal handler itself does not re-enter malloc
>>> (igc_malloc in our case). It just tries to access the memory arena that
>>> is in transient state (in process of allocation).
>>
>> I think you are missing the read/write barriers that MPS puts on its
>> memory.
>>
>> Consider a single object O. At some point in time, MPS copies O to a new
>> address O', as part of the copying GC algorithm. In O it leaves a
>> "tombstone" which tells where O' is now found. Then it puts a barrier on
>> O, so that any access to O let's MPS fix the reference. (All via
>> functions in igc.c. See dflt_fwd which creates the tombstone.)
>
> It is actually clear for me.
> The problem is not with the barrier. The problem is that MPS' barrier
> handler cannot work while the arena is locked to allocate a new
> (completely unrelated) object.
>
> My reading of
> https://memory-pool-system.readthedocs.io/en/latest/design/protix.html#threads
> is that the MPS' barrier handler itself is re-entrant:
The paragraph above what you cited is
.threads.async: POSIX imposes some restrictions on signal handler
functions (see design.mps.pthreadext.analysis.signal.safety). Basically
the rules say the behaviour of almost all POSIX functions inside a
signal handler is undefined, except for a handful of functions which are
known to be “async-signal safe”. However, if it’s known that the signal
didn’t happen inside a POSIX function, then it is safe to call arbitrary
POSIX functions inside a handler.
I read this as them being thinking about whether their SIGSEGV handler can
use POSIX functions or not.
> .threads.async.protection: If the signal handler is invoked because
> of an MPS access, then we know the access must have been caused by
> client code, because the client is not allowed to permit access to
> protectable memory to arbitrary foreign code. In these
> circumstances, it’s OK to call arbitrary POSIX functions inside the
> handler.
And the above I read as saying they can because the client is not
allowed, and blahblah...
> AFAIU, if memory barrier handler were not re-entrant, multi-threading
> would simply not be possible.
I don't understand how you come to that conclusion, sorry.
next prev parent reply other threads:[~2024-07-02 4:33 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-29 19:12 MPS: a random backtrace while toying with gdb Ihor Radchenko
2024-06-29 19:19 ` Pip Cet
2024-06-29 21:46 ` Gerd Möllmann
2024-06-30 4:55 ` Eli Zaretskii
2024-06-30 5:33 ` Gerd Möllmann
2024-06-30 6:16 ` Eli Zaretskii
2024-06-30 6:43 ` Gerd Möllmann
2024-06-30 8:52 ` Eli Zaretskii
2024-06-30 9:43 ` Gerd Möllmann
2024-06-30 10:05 ` Eli Zaretskii
2024-06-30 11:20 ` Gerd Möllmann
2024-06-30 12:16 ` Eli Zaretskii
2024-06-30 12:43 ` Gerd Möllmann
2024-06-30 9:36 ` Helmut Eller
2024-06-30 10:00 ` Eli Zaretskii
2024-06-30 10:24 ` Helmut Eller
2024-06-30 10:43 ` Eli Zaretskii
2024-06-30 18:42 ` Helmut Eller
2024-06-30 18:59 ` Gerd Möllmann
2024-06-30 19:25 ` Pip Cet
2024-06-30 19:49 ` Ihor Radchenko
2024-06-30 20:09 ` Eli Zaretskii
2024-06-30 20:32 ` Pip Cet
2024-07-01 11:07 ` Eli Zaretskii
2024-07-01 17:27 ` Pip Cet
2024-07-01 17:42 ` Ihor Radchenko
2024-07-01 18:08 ` Eli Zaretskii
2024-07-02 7:55 ` Pip Cet
2024-07-02 13:10 ` Eli Zaretskii
2024-07-02 14:24 ` Pip Cet
2024-07-02 14:57 ` Eli Zaretskii
2024-07-02 17:06 ` Pip Cet
2024-07-03 11:31 ` Pip Cet
2024-07-03 11:50 ` Eli Zaretskii
2024-07-03 14:35 ` Pip Cet
2024-07-03 15:41 ` Eli Zaretskii
2024-07-01 2:33 ` Eli Zaretskii
2024-07-01 6:05 ` Helmut Eller
2024-06-30 19:58 ` Eli Zaretskii
2024-06-30 21:08 ` Ihor Radchenko
2024-07-01 2:35 ` Eli Zaretskii
2024-07-01 11:13 ` Eli Zaretskii
2024-07-01 11:47 ` Ihor Radchenko
2024-07-01 12:33 ` Eli Zaretskii
2024-07-01 17:17 ` Ihor Radchenko
2024-07-01 17:44 ` Eli Zaretskii
2024-07-01 18:01 ` Ihor Radchenko
2024-07-01 18:16 ` Eli Zaretskii
2024-07-01 18:24 ` Ihor Radchenko
2024-07-01 18:31 ` Eli Zaretskii
2024-07-01 18:51 ` Ihor Radchenko
2024-07-01 19:05 ` Eli Zaretskii
2024-07-01 19:34 ` Gerd Möllmann
2024-07-01 20:00 ` Ihor Radchenko
2024-07-02 4:33 ` Gerd Möllmann [this message]
2024-07-02 7:05 ` Ihor Radchenko
2024-07-02 7:06 ` Gerd Möllmann
2024-07-01 18:19 ` Gerd Möllmann
2024-07-01 18:23 ` Eli Zaretskii
2024-06-30 11:07 ` Gerd Möllmann
2024-06-30 11:06 ` Gerd Möllmann
2024-06-30 11:05 ` Gerd Möllmann
2024-06-30 9:59 ` Pip Cet
2024-06-30 10:09 ` Eli Zaretskii
2024-06-30 10:16 ` Pip Cet
2024-06-30 10:34 ` Eli Zaretskii
2024-06-30 13:06 ` Pip Cet
2024-06-30 11:10 ` Gerd Möllmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2h6d8h0py.fsf@pro2.fritz.box \
--to=gerd.moellmann@gmail.com \
--cc=eliz@gnu.org \
--cc=eller.helmut@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=pipcet@protonmail.com \
--cc=yantar92@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.