Re: [PATCH 1/2] Move some Windows operations to worker thread

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed,  3 Aug 2022 07:08:21 -0600
> From: Tom Tromey via Gdb-patches <gdb-patches@sourceware.org>
> Cc: Tom Tromey <tromey@adacore.com>
> 
> On Windows, certain debugging APIs can only be called from the thread
> that started (or attached) to the inferior.  Also, there is no way on
> Windows to wait for a debug event in addition to other events.
> Therefore, in order to implement target async for Windows, gdb will
> have to call some functions in a worker thread.
> 
> This patch implements the worker thread and moves the necessary
> operations there.  Target async isn't yet implemented, so this patch
> does not cause any visible changes.

Thanks!

> +  HANDLE bg_thread = CreateThread (nullptr, 0, fn, this, 0, nullptr);

That zero in the 2nd argument of CreateThread means the worker thread
will get the same stack size as the value recorded in the GDB
executable file's header, which is 12MB according to my reading of
gdb/Makefile, at least in my build?  That's unlikely to be required
for this thread, so I suggest to specify a non-zero value there
instead.  I guess 64KB should be enough?

The downside of leaving it at zero is that the OS reserves the
addresses of the entire stack space as for the GDB process, which
could then prevent GDB from allocating enough memory for other
purposes.  And if we could start several such worker threads (is that
possible in some usage scenario?), then we could simply run out of
memory for no good reason, and the next thread will fail to start.