On 09/05/2014 09:48 AM, Eli Zaretskii wrote: >> From: Doug Evans <xdj...@gmail.com> >> Cc: l...@gnu.org, guile-devel@gnu.org, gdb-patc...@sourceware.org >> Date: Fri, 05 Sep 2014 01:26:28 -0700 >> >> we can't physically prevent [users] from starting threads. > > Of course we can: if Guile gives us a way to disable threads, any user > extension that attempts to start a thread will simply fail. > >> We pretty much leave them that way already given the myriad >> of things they can do to mess up gdb without threads. > > ?? The rest of GDB is compiled C code which users cannot change > without recompiling. And it's a single-threaded code. And it's under > our close scrutiny. So I see no problems here. > >> The python side of things is too silent on whether threads are supported >> there. >> https://sourceware.org/gdb/current/onlinedocs/gdb/Basic-Python.html#Basic-Python
I'd be strongly against preventing extensions from using threads. As an example, tromey's wip/prototype gdb frontend written as a python extension to gdb uses threads: https://gitorious.org/gdb-gui Even GDB itself isn't really strictly single-threaded -- e.g., on Windows, we spawn threads to handle I/O: ser-mingw.c: state->thread = CreateThread (NULL, 0, thread_fn, scb, 0, &threadId); Just last night I was debugging something in non-stop mode where a ton of events happen behind the scenes without causing a user-visible stop (a bunch of parallel single-steps), and noticing how the cli/prompt becomes so unresponsive, because the event loop handles either target events or input events in sequence, not in parallel, and thinking that probably to completely fix this we'd need to move stdin/readline handling to a separate thread. Thanks, Pedro Alves
