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