Re: igc, macOS avoiding signals

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> So maybe Pip is right, and MPS always runs in the main (Lisp) thread,
>> even on macOS?  Can you catch it on a non-main thread?
>
> It's well possible that I misunderstand what the MPS guide says about it
> being concurrent (see my reply to Pip), and that the thread I see here
> is something else.
>
> If you don't see an additional thread on Linux, just don't listen to me
> and do what you think is TRT. I don't know anything about MPS internals.

I've investigated this a bit using LLDB. Starting Emacs and attaching to
it, I see 3 threads.

  (lldb) thread list
  Process 55210 stopped
  * thread #1: tid = 0x8b6558, 0x0000000190be51a8 
libsystem_kernel.dylib`__pselect + 8, queue 
    thread #2: tid = 0x8b655c, 0x0000000190bdef54 
libsystem_kernel.dylib`mach_msg2_trap + 8
    thread #3: tid = 0x8b65df, 0x0000000190be0ba4 
libsystem_kernel.dylib`__workq_kernreturn + 8

Thread 1 is Emacs main thread.

  (lldb) thread backtrace
  * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x0000000190be51a8 libsystem_kernel.dylib`__pselect + 8
    frame #1: 0x0000000190be5080 libsystem_kernel.dylib`pselect$DARWIN_EXTSN + 
64
      frame #2: 0x0000000100775948 
emacs`really_call_select(arg=0x000000016f851990) at thread.c:620:16 [opt]
      frame #3: 0x00000001007758bc emacs`thread_select [inlined] flush_stack_ca
      frame #4: 0x00000001007758ac emacs`thread_select(func=<unavailable>, max_
      frame #5: 0x0000000100744e78 
emacs`wait_reading_process_output(time_limit=<unavailable>, n

Thread 2 is MPS' port, for EXC_BAD_ACCESS

  (lldb) thread backtrace
  * thread #2
    frame #0: 0x0000000190bdef54 libsystem_kernel.dylib`mach_msg2_trap + 8
    frame #1: 0x0000000190bf169c libsystem_kernel.dylib`mach_msg2_internal + 232
    frame #2: 0x0000000190be7af8 libsystem_kernel.dylib`mach_msg_overwrite + 480
    frame #3: 0x0000000190bdf29c libsystem_kernel.dylib`mach_msg + 24
      frame #4: 0x000000010080ae20 emacs`protCatchThread [inlined] protCatchOne 
at protxc.c:207:8 [opt]
      frame #5: 0x000000010080adf0 emacs`protCatchThread(p=<unavailable>) at 
protxc.c:284:5 [opt]
    frame #6: 0x0000000190c202e4 libsystem_pthread.dylib`_pthread_start + 136

The protxc.c is from MPS.

Thread 3 is something I can't explain.

  (lldb) thread backtrace
  * thread #3
    frame #0: 0x0000000190be0ba4 libsystem_kernel.dylib`__workq_kernreturn + 8

The __workq_kernreturn should indicate a thread that it is in the
process of finishing, but I have no idea what that could have been.

Anyway, it definitely seems to be the case that MPS is _not_ running GCs
concurrently, unless it would do things that I find highly unlikely.

I find that a bit, let's say, disappointing, TBH :-(.