Yet another threading question...

cmkl cmkleffner at gmx.de
Wed Jul 2 04:48:46 EDT 2003


don't forget to add the -mthreads switch to gcc when compiling AS WELL 
linking your wrapper code with mingw's gcc. In case you use g++ instead 
of gcc for some reason your wrapper maybe depend on the mingw10.dll. 
Dependency walker will tell you....

Another compiler option which may help is  -mms-bitfields
The use of MS compatible bitfield layout is not enabled by default
for some reason. The older mingw gcc has:  -fnative-struct instead

And another complication is the use of win32 unicode (wide character)
functions: In this case you want to add -DUNICODE and -D_UNIOCDE
to your compiler options.

A completly different story is the use of the ctypes module instead.

Hope this helps

Carl

"Kevin" <other at cazabon.com> wrote in message news:<HXQKa.301729$ro6.7464204 at news2.calgary.shaw.ca>...
> I've been pondering the exact same issue, but haven't gotten that far in
> wrapping the 3rd-party C library I'm working with.
> 
> I was thinking of stubbing the callback to a Python function that sets an
> event flag, and have a Python thread monitoring that event to handle it.
> I'm not sure if that will cure your access violation, but it may.  You
> should also make sure that your wrapper gets the GIL (Python Global
> Intepreter Lock) before making the Python function call to set the event.
> 
> Let me know if you try that, or if you get it to work some other way... I'll
> be beating my head into the same problem pretty soon and could use the heads
> up!
> 
> Thanks,
> Kevin Cazabon
> 
> 
> "Jim West" <Jim.West at checklogix.com> wrote in message
> news:mailman.1056639557.22837.python-list at python.org...
> > Good day all,
> >
> >   Ok, I'm starting to get the hang of this Python thing...really pretty
> > cool actually.  Again, thanx to those that have helped me thus far.
> >
> >   I now have another stumbling block to which I would like help.
> >
> >   Ok, here is my enviroment:
> >
> >         Windows 2K
> >         Python 2.2
> >         MinGW and MSys
> >
> >   I'm writing a Python extension to a 3rd party DLL that controls an
> > external hardware toy.
> >
> >   One of the DLL methods is a callback registration interface.  The 3rd
> > party DLL is threaded as the callback is asynchronous.
> >
> >   I'm able to call my extension function via Python to "register" my
> > Python function as the callback function via a C function proxy in the
> > extension.
> >
> >   All is well until the DLL invokes the callback.  When the callback
> > attempts to invoke my "registered" Python function the Python
> > interpreter bails with an access violation.
> >
> >   I'm thinking it may have something to do with threading and thus am
> > asking for your insight to this.
> >
> >   I'm thinking I may have to put my proxy C callback function in it's
> > own thread.  If so, then would some kind soul point me in the right
> > direction as to how to do this with just the MinGW environment since we
> > do not have nor use MSVC++.
> >
> >   Thank you.
> >
> > - Jim
> >
> >
> >




More information about the Python-list mailing list