[Pythonmac-SIG] Carbon events in an interrupt-level routine

[Donovan Preston]

This is part of a message I got from Carbon-dev:

From: "Paul Lalonde" <paullalonde@mac.com>
<snip>
 >>From: Jim Myers <jim@transcena.com>
<snip>
 >>No where can I find any documentation telling me which Carbon calls are
 >>interrupt safe (if any). Can someone point me to the resource somewhere
 >>telling me which Carbon and/or Carbon event calls are interrupt safe?
 >>Finding this type of info has proven fruitless after many hours of
 >>searching.
 >
 >AFAIK, none of the Carbon Event calls are documented to be 
interrupt-safe,
 >although as Eric S. said in a previous post, on X it's not an issue.  
OTOH,
 >a handful of MP calls *are* interrupt-safe (MPSignalSemaphore & co.), 
which
 >is why I used them in my solution.

Well, there goes my idea of having GUSI send MacPython a Carbon Event 
upon I/O completion. In retrospect, it wasn't really the greatest idea 
anyway. So, the likelihood of removing all WaitNextEvent calls from 
MacPython (on OS 9 anyway) seems rather low. However, since it is 
possible to install Carbon Event handlers and still run a WaitNextEvent 
loop, that's OK.

However, there remains the issue of GUSI not being threadsafe on OS X. 
This means that MacPython CFM on Mac OS X is continually generating race 
conditions that probably cause it to eventually crash even on 
single-processor machines. There are two solutions to this problem 
(remember, this is only a problem on X, not on 9):

1) Fix GUSI so that it is thread safe on X by installing mutex locks 
around critical code sections.

2) Swap out GUSI for the native BSD socket libraries. This is the path 
that Mach-O MacPython will take us to.

Personally I vote for #2, as it's a desirable goal anyway because of all 
the other benefits it gives us. As I mentioned to Jack before, as soon 
as the WASTE and Scrap modules are available to Mach-O MacPython, we 
should be able to just run the IDE from a bundled Mach-O python binary. 
Very cool.

Jack: I am going to hopefully have some time this week to spend on this 
task. My goal is to have the IDE up and running in a Bundle, and then we 
can take a look at converting the W code to CarbonEvents. I'm not sure 
how much of a benefit this will be as it complicates the code base 
tremendously if we want to continue to support non-carbon CFM. We'll 
have to wait and see.

Donovan