Re: MPS: a random backtrace while toying with gdb

[Ihor Radchenko <yantar92@posteo.net>]

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:

    .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.

AFAIU, if memory barrier handler were not re-entrant, multi-threading
would simply not be possible.

-- 
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>