Re: igc, macOS avoiding signals

[Gerd Möllmann]

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

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

And now, git grep in MPS, reveals

Concurrent collection
.....................

_`.improv.concurrent`: The MPS currently does not collect
concurrently, however the only thing that makes it not-concurrent is a

:-(