Christopher Barker wrote: > Peter Hanson, on the wxPython list, seems to have identified a bug in the > gestalt module, that may be a Carbon issue. It's a bit of an unusual case: it > freezes up wxPython, when wx is called from other than the main thread. Robin > Dunn suspects that it's a Carbon issue -- gestalt is calling Carbon, and > doing so in the main thread, so you are then trying to call Carbon from more > than one thread, which may be the cause of the problem. I've confirmed that > if you call gestalt from the same thread as wxPython, there is no failure.
Is wx/Mac not already built upon Carbon/Cocoa APIs? Cocoa's GUI APIs certainly aren't thread-safe - all calls must go through the main thread - and I doubt Carbon's GUI APIs are any different. So I'd hazard that Peter's just run afoul of that fundamental limitation of OS X's GUI APIs, and it's purely dumb luck that it didn't happen sooner. In which case, I think the only sensible solution is to rework his application code to ensure all GUI calls are made on the main thread, as I doubt the situation will improve any as wx moves to Cocoa. > As Carbon is deprecated anyway, I guess it's time for gestalt ( or > platform.mac_ver ) to be re-written Python's Carbon modules are deprecated in 2.x and gone in 3.x, so its Carbon.gestalt module is a dead end for Python users. Mac OS X's gestalt APIs are not deprecated, however, so I don't see why platform.mac_ver would need changed. has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
