I tried to use the threading module to start the XML 
RPC server in a different thread (xmlrpcServer itself 
also is a threaded piece of code), but that seems to 
conflict with the mainloop. If you start this 
application, it starts the thread, starts the mainloop 
and stays in there, once you finish the mainloop, the 
thread continues.

You've stumbled on a bug in Framework.mainloop(): it 
doesn't know anything about multiple threads. It gives 
time to other applications (by calling WaitNextEvent) 
but not to other threads within Python.

Also see
http://mail.python.org/pipermail/pythonmac-sig/2002-
April/005416.html

and 

http://mail.python.org/pipermail/pythonmac-sig/2002-
April/005428.html

Logged In: YES 
user_id=45365

Adding an optional time.sleep(0) to the mainloop should do the trick, but unfortunately this won't work with the current MacPython, as time.sleep() is implemented with select(). And while GUSI sleep(0) does the threadswitch sleect(..., 0) doesn't. So this needs to be fixed in timemodule, and then the thread switch can be forced in Framework.Application.mainloop().

Logged In: YES 
user_id=45365

After some discussion on the SIG it turns out this is a rather complicated problem, because WNE() may cause callbacks to be called (for Carbon Event handlers, for instance), and releasing the GIL would mean those callbacks would be hosed.

A solution will have to have all callback wrappers acquire the GIL, and it will either have to make very sure we never enter WNE() or friends with the GIL held, or the callback code will need to be able to handle both the case of being called with the GIL held and the case of being called without it.

Logged In: YES 
user_id=45365

Let's admit this isn't going to be fixed unless someone wants it real bad.

Pieter: if you want it real bad then reopen the bug and I'll find time for it.

Logged In: YES 
user_id=92689

Jack, have you forgotten about autoGIL? It's quite likely that the autoGIL module (as part of the PyObjC project) would fix this issue out of the box on OSX. Do "import autoGIL; autoGIL.installAutoGIL()" before you enter the event loop and the second thread gets time to run.

Logged In: YES 
user_id=45365

If that is true I would be very happy. Could you please investigate this and put it in if it works? Before 2.3b1 please: I don't want to mess with the core of the MacOS support modules after that...

Logged In: YES 
user_id=446428

Probably fixing this will also allow to run a long computation and still use 
the IDE for writing other code, or run commands in interactive mode.
Sounds like a cool feature!

Logged In: YES 
user_id=92689

I finally got around playing with autoGIL in the IDE (briefly, though): it seems 
to work just fine! Reopeing this report.

Jack, I could add autoGIL.c to the Mac tree if you want. A good experiment 
would be to make the PackagaManager threaded...

Logged In: YES 
user_id=45365

What do you mean by "add it to the mac tree"?

Anyway: I would love to have this functionality, but I think it is probably 
prudent to do development on a branch (unless you're pretty sure of it).

Logged In: YES 
user_id=92689

Mac tree: somewhere in Mac/Modules/. It's a completely standalone module, 
it has no impact on the rest of the (Mac)Python source tree. PythonIDE.py 
would import it and call autoGIL.installAutoGIL(). You should have a look ;-)

I'm playing with it now, and somehow it doesn't always quite work like I 
thought. Need to do more testing. It works perfectly in Cocoa apps, but not 
always under W/FrameWork's WaitNextEvent() loop. Don't know whether this 
is an inherent problem, but if so, that would be a reason to move to 
CarbonEvents pretty soon (assuming it _does_ work under 
CarbonEvt.RunApplicationEventLoop()). Hm.

Logged In: YES 
user_id=45365

Ok, it is now clear that I didn't look at the end result of Mark Hammonds 
work, I thought it needed source modifications too. If it is just a module: by 
all means, check it in! And please add it to setup.py too (and either also add 
it to genpluginmodules.py and fullbuild.py, or assign this bug to me later).

Logged In: YES 
user_id=92689

In case it wasn't clear: autoGIL is completely unrelated to Mark's work.

Logged In: YES 
user_id=92689

autoGIL is now part of MacPython and works well with 
Framework.py on Mach-O on OSX. It does _not_ work with the 
GUSI-based CFM OS9 MacPython, nor will it ever, as far as I'm 
concerned. Closing this as "fixed".