Re: [Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

On Dec 6, 2007 9:56 PM, Sean Reifschneider <[EMAIL PROTECTED]> wrote: > Overview (my reading of it): > >PyGTK wakes up 10x a second in it's main loop because signals may be >delivered to another thread and will only get picked up if the mainloop >wakes up. > > In the following thread: >

Re: [Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

The OLPC project is also interested in getting this solved. Can you explain how Gtk uses signals and threads together? The combination strikes me as a recipe for disaster, but I'm probably missing something. --Guido On Dec 6, 2007 8:56 PM, Sean Reifschneider <[EMAIL PROTECTED]> wrote: > Overview

[Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

Overview (my reading of it): PyGTK wakes up 10x a second in it's main loop because signals may be delivered to another thread and will only get picked up if the mainloop wakes up. In the following thread: http://mail.python.org/pipermail/python-dev/2006-September/068569.html it soun

Re: [Python-Dev] PATCH: attribute lookup caching for 2.6

Kevin Jacobs <[EMAIL PROTECTED]> wrote: > On Dec 6, 2007 1:35 AM, Neil Toronto <[EMAIL PROTECTED] > > wrote: > > So I've applied Armin's patch to 2.6 (it was nearly clean) and am > playing with it. cls.name lookups are 15-20% > faster than m

[Python-Dev] tstate_delete_current infinite loop from PyThreadState_DeleteCurrent

Has anyone else ever encountered a situation where a python process gets stuck in an infinite loop within Python/pystate.c tstate_delete_current() called from PyThreadState_DeleteCurrent() when a thread is exiting? (revealed by attaching to the looping process with a debugger) I'm seeing this (ve

Re: [Python-Dev] [Python-3000] Py3k code freeze imminent; 3.0a2 release Friday

> The test_ssl tests are only leaking with the -unetwork option. On my > Ubuntu box they are leaking 1536 references per turn. For heaven's sake > I can't remember how I found the leaking code lines the last time. > Py_DUMP_REFS dumps too many information. I found the leak the last time by narrowi

Re: [Python-Dev] Py3k code freeze imminent; 3.0a2 release Friday

> I see a few tests leaking; in particular test_ssl (1522 refs leaned > per run!) I'm looking at this, but I haven't found anything in the last week... Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python

Re: [Python-Dev] Py3k code freeze imminent; 3.0a2 release Friday

Guido van Rossum wrote: > I see a few tests leaking; in particular test_ssl (1522 refs leaned > per run!) and test_urllib2_localnet (3 per run). Anyone interested in > researching these feel free to do so; just upload a patch and file a > bug if you've squashed the leaks (or some). I see the refer

Re: [Python-Dev] PATCH: attribute lookup caching for 2.6

On Dec 6, 2007 1:35 AM, Neil Toronto <[EMAIL PROTECTED]> wrote: > So I've applied Armin's patch to 2.6 (it was nearly clean) and am > playing with it. cls.name lookups are 15-20% faster than mine, and > inst.name lookups are 5-10% faster. His is also winning on hasattr calls > (succeeding and fail

Re: [Python-Dev] Py3k code freeze imminent; 3.0a2 release Friday

Guido van Rossum wrote: > The buildbot is green for Solaris also, so I think we're in good > shape. I don't see any green buildbots for Windows though, but Windows > is always a flakey situation; Christian, what's your assessment? test_mailbox is still failing with lots of errors. The module needs