Re: MPS: a random backtrace while toying with gdb

[Gerd Möllmann]

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.