Re: [Python-Dev] Atomic instructions for reference count increment/decrement

[Daniel Stutzbach]

On Wed, Dec 17, 2008 at 7:33 PM, Arnar Birgisson  wrote:

> >From the discussion about getting rid of the GIL lately, what I read
> from it is that reference counting is the main obstacle. My question
> is, why aren't hardware supported atomic increments and decrements
> being used for the reference counters?


As far as I'm told they are
> available on most modern platforms (on x86 it is the LOCK instruction
> prefix)


True.


> and these incur little overhead.


False, due to the costs of maintaining cache coherency.

I'd be very happy with pointers to previous discussion on the matter
> or simple arguments why this would not apply to the Python reference
> counting mechanism.
>

Adam Olsen actually tried it.  See:
http://mail.python.org/pipermail/python-dev/2007-September/074645.html

Other message in that thread describe the problem in more detail.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] Atomic instructions for reference count increment/decrement

[Arnar Birgisson]

Hi all,

I'm new here, so bear with me. I tried googling this, but the closest
I came up with was a post from 2000.

>From the discussion about getting rid of the GIL lately, what I read
from it is that reference counting is the main obstacle. My question
is, why aren't hardware supported atomic increments and decrements
being used for the reference counters? As far as I'm told they are
available on most modern platforms (on x86 it is the LOCK instruction
prefix) and these incur little overhead.

I'd be very happy with pointers to previous discussion on the matter
or simple arguments why this would not apply to the Python reference
counting mechanism.

cheers,
Arnar
___
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] Calling the GC less often when there are lots of long-lived objects

[Antoine Pitrou]

Martin v. Löwis  v.loewis.de> writes:
> 
> So despite the organizational overhead, I'd appreciate if you could
> create separate patches, if not separate issues.

Ok, I'm gonna do that.

Regards

Antoine.


___
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] Calling the GC less often when there are lots of long-lived objects

[Martin v. Löwis]

> I've removed the threshold in the latest patches because it didn't make much
> sense when a few long-lived objects contained a lot of objects not tracked by
> the GC.
> 
> Another improvement I've included in the latest patches (but which is
> orthogonal to the algorithmic change) is that simple tuples and even simple
> dicts are not tracked by the GC if they don't need to. A few examples
> (gc.is_tracked() is a new function which returns True if an object is tracked
> by the GC):

As they are orthogonal, I think they should be considered separately,
but in particular committed separately. FWIW, I'm in favor of both
(but haven't reviewed the non-cyclic tuples one yet).

So despite the organizational overhead, I'd appreciate if you could
create separate patches, if not separate issues.

Regards,
Martin
___
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] The endless GIL debate: why not remove thread support instead?

[Greg Ewing]

Nick Coghlan wrote:


Actually, I believe 3.0 already took a big step towards allowing this by
changing the way modules are initialised.


It's a step, but I wouldn't call it a big one. There are
many other problems to be solved before fully independent
interpreters are possible.

--
Greg
___
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] Please test OSX installer

[Alexander Belopolsky]

I've installed it on a MacBook Air running Leopard (10.5.6).
Installer ran like a charm, but when I ran the following in IDLE:

>>> from test.regrtest import main
>>> main()

I got a "Problem Report for Python" pop-up.  Skip to "///" for
"Problem Details".  Interestingly, the test completed with the
following report:

286 tests OK.
3 tests failed:
test_descr test_file test_subprocess
...
3 skips unexpected on darwin:
test_ioctl test_bsddb185 test_univnewlines

This suggests that the crash was in a subprocess.


///

Process: Python [1203]
Path:/Applications/MacPython 2.5/IDLE.app/Contents/MacOS/Python
Identifier:  Python
Version: ??? (???)
Code Type:   X86 (Native)
Parent Process:  Python [1027]

Date/Time:   2008-12-17 16:57:52.804 -0500
OS Version:  Mac OS X 10.5.6 (9G55)
Report Version:  6

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x, 0x
Crashed Thread:  0

Thread 0 Crashed:
0   libSystem.B.dylib   0x90c70e42 __kill + 10
1   libSystem.B.dylib   0x90ce323a raise + 26
2   libSystem.B.dylib   0x90cef679 abort + 73
3   org.python.python   0x004bd33f posix_getloadavg + 0
(posixmodule.c:7961)
4   org.python.python   0x0048571e PyEval_EvalFrameEx +
18973 (ceval.c:3596)
5   org.python.python   0x00487731 PyEval_EvalCodeEx + 1819
(ceval.c:2875)
6   org.python.python   0x004878e5 PyEval_EvalCode + 87 
(ceval.c:520)
7   org.python.python   0x004ab810 PyRun_StringFlags + 243
(pythonrun.c:1273)
8   org.python.python   0x004ab8d7 PyRun_SimpleStringFlags
+ 72 (pythonrun.c:900)
9   org.python.python   0x004b84c5 Py_Main + 1296 (main.c:521)
10  Python  0x1f8e 0x1000 + 3982
11  Python  0x1eb5 0x1000 + 3765

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x  ebx: 0x90cef639  ecx: 0xb1dc  edx: 0x90c70e42
  edi: 0x008001c0  esi: 0x  ebp: 0xb1f8  esp: 0xb1dc
   ss: 0x001f  efl: 0x0282  eip: 0x90c70e42   cs: 0x0007
   ds: 0x001f   es: 0x001f   fs: 0x   gs: 0x0037
  cr2: 0x0048d191

Binary Images:
0x1000 - 0x1fff +Python ??? (???) /Applications/MacPython
2.5/IDLE.app/Contents/MacOS/Python
  0x3f1000 -   0x4e7fe3 +org.python.python 2.5a0 (2.5)
/Library/Frameworks/Python.framework/Versions/2.5/Python
0x8fe0 - 0x8fe2db43  dyld 97.1 (???)
<100d362e03410f181a34e04e94189ae5> /usr/lib/dyld
0x90c02000 - 0x90d69ff3  libSystem.B.dylib ??? (???)
 /usr/lib/libSystem.B.dylib
0x946bd000 - 0x946c1fff  libmathCommon.A.dylib ??? (???)
/usr/lib/system/libmathCommon.A.dylib
0x - 0x1780  libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib



On Wed, Dec 17, 2008 at 4:05 PM, "Martin v. Löwis"  wrote:
> I just created an OSX installer for 2.5.3c1. As it's the first time
> I do that, I'd appreciate if somebody could test it and report whether
> it works (as well as the 2.5.2 one did).
>
> http://www.python.org/download/releases/2.5.3/
>
> Regards,
> Martin
> ___
> 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/alexander.belopolsky%40gmail.com
>
___
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] Please test OSX installer

[Guido van Rossum]

Worked flawlessly both on an x86 MacBook Pro running Leopard (10.5)
and a ppc PowerBook G4 running Tiget (10.4).

The only issue is that the Python logo makes the text in the sidebar
of the installer hard to read.

I didn't test the GUI app.

Thanks for doing this!

--Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, Dec 17, 2008 at 1:05 PM, "Martin v. Löwis"  wrote:
> I just created an OSX installer for 2.5.3c1. As it's the first time
> I do that, I'd appreciate if somebody could test it and report whether
> it works (as well as the 2.5.2 one did).
>
> http://www.python.org/download/releases/2.5.3/
___
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] Calling the GC less often when there are l ots of long-lived objects

[Antoine Pitrou]

Antoine Pitrou  pitrou.net> writes:
> 
> We could let the user configure the threshold between the old policy and the 
new
> policy. Currently it is hard-wired to a value of 1 (that is, 1
> long-lived objects tracked by the GC).

I've removed the threshold in the latest patches because it didn't make much
sense when a few long-lived objects contained a lot of objects not tracked by
the GC.

Another improvement I've included in the latest patches (but which is
orthogonal to the algorithmic change) is that simple tuples and even simple
dicts are not tracked by the GC if they don't need to. A few examples
(gc.is_tracked() is a new function which returns True if an object is tracked
by the GC):

>>> import gc
>>> gc.is_tracked(())
False
>>> gc.is_tracked((1,2))
False
>>> gc.is_tracked((1,(2, "a", None)))
False
>>> gc.is_tracked((1,(2, "a", None, {})))
True

>>> d = {}
>>> gc.is_tracked(d)
False
>>> d[1,2] = 3,4
>>> gc.is_tracked(d)
False
>>> d[5] = None, "a", (1,2,3)
>>> gc.is_tracked(d)
False
>>> d[6] = {}
>>> gc.is_tracked(d)
True
>>> gc.is_tracked(d[6])
False

Regards

Antoine.


___
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] Please test OSX installer

[Martin v. Löwis]

I just created an OSX installer for 2.5.3c1. As it's the first time
I do that, I'd appreciate if somebody could test it and report whether
it works (as well as the 2.5.2 one did).

http://www.python.org/download/releases/2.5.3/

Regards,
Martin
___
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 3.0 urllib fails with chunked HTTP responses

[Guido van Rossum]

The inheritance from io.RawIOBase seems fine.

--Guido van Rossum (home page: http://www.python.org/~guido/)



On Mon, Dec 15, 2008 at 11:19 AM, Jeremy Hylton  wrote:
> I have a patch that appears to fix this bug
> http://bugs.python.org/file12361/urllib-chunked.diff
> but I'm not sure about its interaction with the io module and
> RawIOBase.  Is there a new IO expert who could take a look at it for
> me?
>
> Jeremy
>
> On Sun, Dec 14, 2008 at 11:06 PM, Jeremy Hylton  wrote:
>> This bug is pretty serious, because urllib will insert garbage into
>> the application-visible data for a chunked response.  It simply
>> ignores the fact that it's reading a chunked response and includes the
>> chunked header data is payload data.  The original bug was reported in
>> September, but no one noticed it.  It was reported again recently.
>>
>> http://bugs.python.org/issue3761
>> http://bugs.python.org/issue4631
>>
>> I suspect we'd want to get a 3.0.1 out as soon as this is fixed, but
>> that's not my call.
>>
>> Jeremy
>>
> ___
> 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
>
___
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] Calling the GC less often when there are lots of long-lived objects

[Kevin Jacobs]

On Tue, Dec 16, 2008 at 8:00 PM, Antoine Pitrou  wrote:

> Christian Heimes  cheimes.de> writes:
> >
> > Is it reasonable to implement multiple policies so the user can switch
> > between them? Or is the new algorithm superior in all cases?
>
> 
>

I'll test your patch, as I currently have to micro-manage the garbage
collector in several of my algorithms or else they degenerate into
almost continuous collection.

Results in a day or two.

~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