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

[Christian Heimes]

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
extra embracement and love on Windows. Most to all of the problems are
related to the newline separator \r\n.

Some modules are also failing when I run a refleak regression test, see
http://bugs.python.org/issue1540

I've ironed out the last cosmetic problems in the PCbuild9 directory and
profile guided optimization builds. A PGO version can be build with
"build_pgo -2" (runs the complete unit test suite) or "build_pgo" (runs
PyBench) in a VS 2008 command shell. The x64 builds are looking fine
except of tkinter (it doesn't build) but I'm not able to test the x64
version on my computer.

Could you please add two comments to the release notes for Windows users?

* On Windows Python can't be run from a directory with non ASCII chars
in its path name. #1342

* The current releases of MinGW and Cygwin can't build Python extensions
since they don't support msvcr90.dll. The necessary bits and pieces are
already in Python and cygwin cvs.

> 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).

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.

Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Kevin Jacobs <[EMAIL PROTECTED]>]

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 failing) on classes, but mine is winning on hasattr
> calls on instances. I want to poke at it a bit to find out why.
>

I hope folks have noticed that I've done some significant cleanup and
forward porting some months ago at

http://bugs.python.org/issue1700288

-Kevin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Christian Heimes]

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 reference leaks, too. I didn't notice the ssl leaks before
because I usually don't run the refleak test with -unetwork or -uall.

./python Lib/test/regrtest.py -R1:2 -unetwork test_ssl

I've started to work on a patch that adds GC support to Modules/_ssl.c
PySSLObject but I don't have time to finish it until tonight.
http://bugs.python.org/issue1469

Christian

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Bill Janssen]

> 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-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Bill Janssen]

> 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 narrowing down the tests, test by
test.

It was leaking sockets because they got dropped on the floor when a
connect failed.  I'll look at this some more this weekend.

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] tstate_delete_current infinite loop from PyThreadState_DeleteCurrent

[Gregory P. Smith]

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 (very rarely, reproducing it is difficult).  In this case
its python 2.4.3 but that code does not appear to have changed since then.

-gps
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Neil Toronto]

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 mine, and
> inst.name  lookups are 5-10% faster. His is also
> winning on hasattr calls
> (succeeding and failing) on classes, but mine is winning on hasattr
> calls on instances. I want to poke at it a bit to find out why.
> 
> 
> I hope folks have noticed that I've done some significant cleanup and 
> forward porting some months ago at
> 
> http://bugs.python.org/issue1700288

Excellent. I tried this as well. This is guarding cache access with 
PyString_CheckExact (as it should) rather than asserting PyString_Check, 
plus a few other cleanups. It runs nearly as fast as Armin's, and still 
faster than mine and much faster than without.

Neil

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Sean Reifschneider]

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 sounds like the patch at:

   http://bugs.python.org/issue1564547

doesn't solve the problem.  A recent gnome bug brings this issue back up:

   http://bugzilla.gnome.org/show_bug.cgi?id=481569

I went ahead and closed the python issue as "rejected" to hopefully get
some more activity on it.

I thought about this some, and I wondered if there was some way we could
signal the sleeping thread when a signal came in on another thread.  Like
perhaps we could make some code to create a pipe, and put it someplace that
all threads could get access to.  Then, if a thread gets a signal, write on
this pipe.  The mainloop could include this file descriptor in the set it's
watching, so it would wake up when the signal came in.

Is this something Python should provide, or something PyGTK should do?  If
an approach like the above would work, we could make it so that select()
always created this file descriptor and added it to one of the FD sets, so
that it would do the right thing behind the scenes.

I have no idea if this is a reasonable approach, but it's something that
came to mind when I thought about the problem and was an approach I didn't
see mentioned before in the discussion.

Thanks,
Sean
-- 
 I live my life like I type; Fast with lots of mistakes.
Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]>
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
  Back off man. I'm a scientist.   http://HackingSociety.org/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 (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 sounds like the patch at:
>
>http://bugs.python.org/issue1564547
>
> doesn't solve the problem.  A recent gnome bug brings this issue back up:
>
>http://bugzilla.gnome.org/show_bug.cgi?id=481569
>
> I went ahead and closed the python issue as "rejected" to hopefully get
> some more activity on it.
>
> I thought about this some, and I wondered if there was some way we could
> signal the sleeping thread when a signal came in on another thread.  Like
> perhaps we could make some code to create a pipe, and put it someplace that
> all threads could get access to.  Then, if a thread gets a signal, write on
> this pipe.  The mainloop could include this file descriptor in the set it's
> watching, so it would wake up when the signal came in.
>
> Is this something Python should provide, or something PyGTK should do?  If
> an approach like the above would work, we could make it so that select()
> always created this file descriptor and added it to one of the FD sets, so
> that it would do the right thing behind the scenes.
>
> I have no idea if this is a reasonable approach, but it's something that
> came to mind when I thought about the problem and was an approach I didn't
> see mentioned before in the discussion.
>
> Thanks,
> Sean
> --
>  I live my life like I type; Fast with lots of mistakes.
> Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]>
> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
>   Back off man. I'm a scientist.   http://HackingSociety.org/
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Adam Olsen]

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:
>
>http://mail.python.org/pipermail/python-dev/2006-September/068569.html
>
> it sounds like the patch at:
>
>http://bugs.python.org/issue1564547
>
> doesn't solve the problem.  A recent gnome bug brings this issue back up:
>
>http://bugzilla.gnome.org/show_bug.cgi?id=481569
>
> I went ahead and closed the python issue as "rejected" to hopefully get
> some more activity on it.
>
> I thought about this some, and I wondered if there was some way we could
> signal the sleeping thread when a signal came in on another thread.  Like
> perhaps we could make some code to create a pipe, and put it someplace that
> all threads could get access to.  Then, if a thread gets a signal, write on
> this pipe.  The mainloop could include this file descriptor in the set it's
> watching, so it would wake up when the signal came in.
>
> Is this something Python should provide, or something PyGTK should do?  If
> an approach like the above would work, we could make it so that select()
> always created this file descriptor and added it to one of the FD sets, so
> that it would do the right thing behind the scenes.
>
> I have no idea if this is a reasonable approach, but it's something that
> came to mind when I thought about the problem and was an approach I didn't
> see mentioned before in the discussion.

That's pretty much what issue1564547 does.  I think there's two marks
against it:
* Using poll and fd's is pretty platform specific for what should be a
general-purpose API
* Handling signals is icky, hard to get right, and nobody trusts it

Since I don't think there's any more immediate solutions I'll provide
a plan B: my threading patch[1] will have a dedicated signal handler
thread, allowing them to be processed regardless of one blocked
thread.  I'm also providing an interrupt API the gtk bindings could
use to support wakeups, while keeping the poll+fd details private.


[1] http://code.google.com/p/python-safethread/
  The patch is, of course, out of date.

-- 
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com