Next: Exception Handling, Previous: Basic Python, Up: Python API [Contents][Index]
GDB is not thread-safe. If your Python program uses multiple threads, you must be careful to only call GDB-specific functions in the GDB thread. GDB provides some functions to help with this.
As mentioned earlier (see Basic Python), certain signals must be
delivered to the GDB main thread. The block_signals
function returns a context manager that will block these signals on
entry. This can be used when starting a new thread to ensure that the
signals are blocked there, like:
with gdb.block_signals(): start_new_thread()
This is a subclass of Python’s threading.Thread
class. It
overrides the start
method to call block_signals
, making
this an easy-to-use drop-in replacement for creating threads that will
work well in GDB.
This causes GDB to react as if the user had typed a control-C
character at the terminal. That is, if the inferior is running, it is
interrupted; if a GDB command is executing, it is stopped;
and if a Python command is running, KeyboardInterrupt
will be
raised.
Unlike most Python APIs in GDB, interrupt
is
thread-safe.
Put event, a callable object taking no arguments, into
GDB’s internal event queue. This callable will be invoked at
some later point, during GDB’s event processing. Events
posted using post_event
will be run in the order in which they
were posted; however, there is no way to know when they will be
processed relative to other events inside GDB.
Unlike most Python APIs in GDB, post_event
is
thread-safe. For example:
(gdb) python >import threading > >class Writer(): > def __init__(self, message): > self.message = message; > def __call__(self): > gdb.write(self.message) > >class MyThread1 (threading.Thread): > def run (self): > gdb.post_event(Writer("Hello ")) > >class MyThread2 (threading.Thread): > def run (self): > gdb.post_event(Writer("World\n")) > >MyThread1().start() >MyThread2().start() >end (gdb) Hello World
Next: Exception Handling, Previous: Basic Python, Up: Python API [Contents][Index]