[Pythonmac-SIG] Re: CarbonEvents -> MacPython

[Donovan Preston]

Hi Just,

I wanted to respond to this publicly to let everyone know that yes, I am 
very interested in this module and am using it fairly heavily in some OS 
X desktop applications. I apologize to everyone that I've either been 
too busy or too lazy to report on my general progress building killer 
Carbon Events-based applications on both OS X and OS 9. :-)

On Wednesday, December 12, 2001, at 10:22 AM, Just van Rossum wrote:
>
> Hi Donovan,
>
>> From the CVS log msgs I understand that you're the original author of 
>> the
> CarbonEvt module. I'm doing some work on it (like making it build under 
> CW), but
> there is at least one issue that's beyond me: this MP stuff in the 
> event handler
> code and in RunApplicationEventLoop(). I see USE_MAC_MP_MULTITHREADING 
> is
> manually defined. However, if it _is_ defined, at least
> RunApplicationEventLoop() doesn't work under OS 9.x (it throws a 
> SystemError
> exception, which is bad all by itself...). So for now I've simply 
> disabled it.
> Are you still interested in the module? If so, maybe we can sort out a 
> few
> things together. Most of my changes are already in CVS.

I also have a few changes to the module on my local hard drive at home 
which make the module build properly under OS X. I have been unable to 
figure out how to create a diff and this is the reason why I haven't 
submitted the changes to Jack (they are quite trivial, however.) If 
someone could tell me how I could generate a diff from the terminal on 
OS X, on a CVS checkout which I have modified locally, I would 
appreciate it. Perhaps then this module can become part of the standard 
build process and I can stop worrying about making sure it is there 
separately.

Here's the issue I had with RunApplicationEventLoop which I tried to 
solve with the code between USE_MAC_MP_MULTITHREADING: (I put it between 
that define specifically so someone could turn it off if it was 
problematic)

When python calls a C function, it assumes that C function COULD be 
calling the C Python api to manipulate python objects, call functions, 
etc. Therefore it hands the global interpreter lock to the C function 
and waits until the function returns before executing any more python 
code. Simple enough for doing most things in C like calculating the 
value of 2 + 2, building a python object out of the result, and 
returning it to python.

But when you call RunApplicationEventLoop, you are entering into a black 
hole from which control will not be returned until your app exits.

Also, if you have registered any event handlers before calling 
RunApplicationEventLoop (your app would be pretty boring if you hadn't), 
the OS will call your code from within the black hole of 
RunApplicationEventLoop and the python interpreter will be kicked off 
again.

Problem is, the OS sometimes likes to call an event handler __while__ 
another event is still being handled. This causes two threads of 
execution to try to execute python code in the same interpreter at the 
same time. Bad news.

So, I needed a mutex lock. I can't use a python lock, because acquiring 
it requires executing python code, which would be bad if some python 
code is already running (somebody correct me if I'm wrong here.) Apple 
never needed to define traditional mutex locks because the toolbox API 
is a cooperative one UNTIL Apple came out with MultiProcessor machines, 
so the mutex lock API I picked (for the very reason that it IS 
compatible with OS 9, as opposed to some BSD call...) is 
MPCreateCriticalRegion/MPDeleteCriticalRegion/MPEnterCriticalRegion/MPExitCriticalRegion.

To make a long story short, I specifically chose this API for it's OS 9 
compatibility. As a matter of fact, I had at one time (months ago) 
compiled it on OS 9 as a proof-of-concept for my boss to prove that yes 
indeed the apps I am developing will be (eventually) deployable on OS 9. 
So it surprises me that you are getting an error. Sigh.

I also see just now (three hours after I started writing this message) 
that you've put some error handling code into the event handler. That's 
one of the pieces of code that's sitting on my hard drive waiting to be 
diffed to the CVS. (I believe that may be all, actually.)

Also, while I have your attention, has anyone made any progress on the 
two remaining modules needed to be built in order to run the IDE on pure 
Mach-O/Framework enabled python? (Scrap and WASTE, I believe) If not I 
may tackle it soon.

I'm very excited about helping make MacPython kick ass, and sorry that I 
don't take more time out to give a progress report on what I'm doing to 
the list.

Donovan