Yet another threading question...

[Kevin]

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
>
>
>