[Lldb-commits] [lldb-dev] Patches for python bindings

Filipe Cabecinhas filcab at gmail.com
Wed Mar 14 16:15:29 PDT 2012

Hi Enrico,

It doesn't necessarily depend on SWIG's thread features.  
The thing is: if we're in a multithreading python environment (which is what we have to assume, when there is a python program using lldb's event API), then the callback helper function will lock the GIL before calling python code. If SWIG isn't run with the "-threads" argument, then those calls are no-ops (SWIG_PYTHON_THREADS is undefined and those two symbols will be defined to nothing).

I'm locking the GIL because I'm planning on fixing lldb's ScriptInterpreterPython code to lock the GIL when it needs to. When that happens, these locks will need to be here to make the callback feature continue working.

There's also no problem in having several threads calling LLDBSwigPythonCallPythonLogOutputCallback at the same time: the callback would be the one responsible for any races with output channels, since LLDB doesn't know anything about what will happen to the strings in the callback function.

If you would prefer to leave the threading issue to a later date, I can send a commit without those two lines, too.



On Wednesday, March 14, 2012 at 8:42 PM, Enrico Granata wrote:

> Hi Filipe,
> I have also looked at lldb-enable-log-callback.patch
> As far as I can tell, it depends on SWIG's threading support for its operation (since otherwise it looks like nothing prevents multiple threads from calling LLDBSwigPythonCallPythonLogOutputCallback).
> Is there a way to change the patch so it does not depend on that feature, since apparently it is not working well with the existing LLDB code?
> Thanks,
> Enrico Granata
> ✉ egranata@.com
> ✆ (408) 972-7683

More information about the lldb-commits mailing list