Inadvertently run inferior threads

[Eli Zaretskii <eliz@gnu.org>]

This happens to me quite a lot when I debug Emacs on Windows and
invoke a command that calls a function in the inferior:

  Breakpoint 3, font_matches_spec (type=4, font=0x88b678, spec=22662725,
      backend=33216, logfont=0x88b860) at w32font.c:1197
  1197                      if (! memq_no_quit (val, support))
  (gdb) p val
  $1 = -7860248
  (gdb) xtype
  Lisp_Symbol
  (gdb) xsymbol
  $2 = (struct Lisp_Symbol *) 0x1913eb0 <dumped_data+3723472>
  "mathematical-bold"
  (gdb) n
  1198                        return 0;
  (gdb) p support
  $3 = 25938803
  (gdb) pp support
  [New Thread 20240.0x1134]
  [New Thread 20240.0x445c]
  (symbol arabic hebrew cyrillic greek phonetic latin)
  (gdb) c
  Continuing.
  Cannot execute this command while the selected thread is running.
  (gdb) info threads
    Id   Target Id         Frame
    6    Thread 20240.0x445c (running)
    5    Thread 20240.0x1134 (running)
    4    Thread 20240.0x24bc (running)
    3    Thread 20240.0x1cb4 (running)
    2    Thread 20240.0xb5c (running)
  * 1    Thread 20240.0x464c (running)

"pp" is in this case the command that invokes an inferior function,
see src/.gdbinit in the Emacs sources for the details.  'support' is a
Lisp object, a list in this case, and "pp" displays it in
human-readable form.  Note that invoking "pp" started 2 new threads in
the inferior, for some reason -- neither the command itself nor the
function it invokes start any threads.  It's Windows itself that
starts them, so it seems.

I only see this on Windows 7, never on XP (didn't try newer versions).

Once this happens, the debugging session seems to be ruined: the only
thing I can do is kill the inferior and quit the debugger.  Because
there doesn't seem to be any way of stopping the threads again, not on
Windows anyway.

Am I the only one who sees this annoying problem?  Does anyone know
how to avoid it, or where to look for fixing it?

TIA