Re: Multi-threaded wrapping

On 30.09.22 08:11, Rob McDonald wrote:
> So, to make this work, we would like to grab foo's GUI lock before executing dosomething() and then release it when complete.
> 
> Is there a way to wrap every function / method wrapped with SWIG?  I.e. add lock() and unlock() before/after every call?

I'm also just a beginner with swig, but maybe have a look how the
exception handling can be done. In the C# bindings it uses exception.i,
and then you can define a method that is wrapping every native call
on the native side (to catch exceptions and pass them to managed
code without the exception crossing the boundary).

Does that help?

All the best,

    Mario


> I've read the docs on code insertion <https://www.swig.org/Doc4.0/SWIGDocumentation.html#SWIG_nn40>, but that seems to be at a bigger picture level (than every
> single call).  But maybe I'm misunderstanding the docs.
> 
> I can theoretically go through and modify every one of my API calls on the C++ side.  I'd really rather not do that...  For one, there are a lot of call sites
> -- this is will become a big maintenance burden to make sure all sites are modified and all future calls added also get this treatment.  For two, this code is
> sometimes compiled without the GUI at all (and therefore no event loop and no lock).  So all of the code would need to be #if conditional -- it will likely end
> up pretty ugly.  I think it will be much more maintainable and much more clean if SWIG can take care of all of this in one place.
> 
> Thanks again for any help,
> 
> Rob
> 
> 
> 
> 
> 
> 
> 
> 
> On Tue, Sep 20, 2022 at 11:06 AM Burlen Loring <[email protected] <mailto:[email protected]>> wrote:
> 
>     the "-threads" option tells SWIG to release the GIL before entering wrapped C++ code. This lets Python interpreter to continue to run while the wrapped C++
>     code executes. However, this means that any calls made into the Python C-API initiated from your wrapped code must first acquire the "GIL" to prevent the
>     interpreter state from becoming corrupted. Of course you also need release GIL when done calling into the Python C-API. That's pretty much all there is to it.
> 
>     For more info see:
> 
>     https://docs.python.org/3/c-api/init.html#thread-state-and-the-global-interpreter-lock
>     <https://docs.python.org/3/c-api/init.html#thread-state-and-the-global-interpreter-lock>
>     https://www.swig.org/Doc4.0/Python.html#Python_multithreaded <https://www.swig.org/Doc4.0/Python.html#Python_multithreaded>
> 
>     Also may be instructive to look at the code SWIG generates when you add the -threads option. You can grep for the word THREAD in the C++ code SWIG spits out.
> 
>     Hope this helps
> 
> 
>     On 9/19/22 09:48, William S Fulton wrote:
>>
>>
>>     On Mon, 12 Sept 2022 at 18:55, Rob McDonald <[email protected] <mailto:[email protected]>> wrote:
>>
>>         I have a C++ application with an event driven GUI (using FLTK) that is currently wrapped with Swig for Python.
>>
>>         I can make calls (with no GUI loaded) to the exposed API.  I can also launch the GUI from Python (and FLTK event loop) and interact with the graphical
>>         program for a while -- when satisfied, I can terminate the event loop to return control to Python.
>>
>>         I would like to be able to leave the application GUI active (event loop still running) and return control to Python.  The Python side might actually
>>         be a separate GUI with its own event loop.  The two loops will need to communicate occasionally -- I can likely initiate all communication from the
>>         Python side.
>>
>>         I believe I will need to run Swig with the 'threads' option.  I also need to set up some sort of lock so the C++ event loop pauses when the C++ API is
>>         responding to a request from the Python side.
>>
>>         Can anyone give any pointers on how to achieve this?  Are there any examples of this available online?
>>
>>
>>     There is an example of the 'threads' option in the SWIG test-suite. See https://github.com/swig/swig/blob/master/Examples/test-suite/python_threads.i
>>     <https://github.com/swig/swig/blob/master/Examples/test-suite/python_threads.i> with associated runtime test
>>     https://github.com/swig/swig/blob/master/Examples/test-suite/python/python_threads_runme.py
>>     <https://github.com/swig/swig/blob/master/Examples/test-suite/python/python_threads_runme.py>. That's all I can find.
>>
>>     William
>>
>>
>>     _______________________________________________
>>     Swig-user mailing list
>>     [email protected] <mailto:[email protected]>
>>     https://lists.sourceforge.net/lists/listinfo/swig-user <https://lists.sourceforge.net/lists/listinfo/swig-user>
> 
> 
> 
> _______________________________________________
> Swig-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/swig-user



Viele Grüße,

    Mario Emmenlauer


--
Mario Emmenlauer                                  Tel: +49-176-23463809
Balanstr. 43                              mailto: mario * emmenlauer.de
81669 Muenchen                                 http://www.emmenlauer.de


_______________________________________________
Swig-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/swig-user