[Python-bugs-list] [ python-Bugs-539990 ] Framework.mainloop() - multiple threads
SourceForge.net
noreply@sourceforge.net
Fri, 20 Jun 2003 13:38:46 -0700
Bugs item #539990, was opened at 2002-04-05 23:29
Message generated for change (Comment added) made by jvr
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470
Category: Macintosh
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Pieter Claerhout (pclaerhout)
Assigned to: Just van Rossum (jvr)
Summary: Framework.mainloop() - multiple threads
Initial Comment:
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
----------------------------------------------------------------------
>Comment By: Just van Rossum (jvr)
Date: 2003-06-20 22:38
Message:
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".
----------------------------------------------------------------------
Comment By: Just van Rossum (jvr)
Date: 2003-05-03 00:46
Message:
Logged In: YES
user_id=92689
In case it wasn't clear: autoGIL is completely unrelated to Mark's work.
----------------------------------------------------------------------
Comment By: Jack Jansen (jackjansen)
Date: 2003-05-03 00:36
Message:
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).
----------------------------------------------------------------------
Comment By: Just van Rossum (jvr)
Date: 2003-05-02 22:30
Message:
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.
----------------------------------------------------------------------
Comment By: Jack Jansen (jackjansen)
Date: 2003-05-02 22:22
Message:
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).
----------------------------------------------------------------------
Comment By: Just van Rossum (jvr)
Date: 2003-05-02 20:28
Message:
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...
----------------------------------------------------------------------
Comment By: Jurjen N.E. Bos (jneb)
Date: 2003-04-25 11:35
Message:
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!
----------------------------------------------------------------------
Comment By: Jack Jansen (jackjansen)
Date: 2003-02-25 11:43
Message:
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...
----------------------------------------------------------------------
Comment By: Just van Rossum (jvr)
Date: 2003-02-24 19:51
Message:
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.
----------------------------------------------------------------------
Comment By: Jack Jansen (jackjansen)
Date: 2003-02-24 17:45
Message:
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.
----------------------------------------------------------------------
Comment By: Jack Jansen (jackjansen)
Date: 2002-04-22 16:03
Message:
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.
----------------------------------------------------------------------
Comment By: Jack Jansen (jackjansen)
Date: 2002-04-07 23:26
Message:
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().
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470