On Sun, May 16, 2010 at 22:52, Victor Stinner
wrote:
> I didn't followed last development around the GIL. Can you explain me why
> Python should have its own scheduler whereas each OS has already its own
> scheduler?
Because the GIL locks and unlocks threads, in practice, it already
have. But the
I've repeated this setup with OS X 10.4 (Tiger). Some changes to the
XML file were necessary, because I'd installed a non-system Python,
twisted, and zope.interface on this machine, and because on Tiger,
launchd daemon were not allowed to set their group ID. Here's the Tiger
version, which again
Martin v. Löwis wrote:
> OSX doesn't really support thread affinity. The affinity API that they
> have is described on
>
> http://developer.apple.com/mac/library/releasenotes/Performance/RN-AffinityAPI/index.html
>
> You can't bind a thread to specific core with it, though, but you can
> reques
Bill Janssen wrote:
> Nick Coghlan wrote:
>
>> Bill Janssen wrote:
>>> As far as I'm concerned, just tying all of
>>> the program's threads to a single core would be fine, though I imagine
>>> others would differ.
>> Which can be done through the OS tools for setting an application's CPU
>> affin
Nick Coghlan wrote:
> Bill Janssen wrote:
> > As far as I'm concerned, just tying all of
> > the program's threads to a single core would be fine, though I imagine
> > others would differ.
>
> Which can be done through the OS tools for setting an application's CPU
> affinity.
Yes, as I say, if
Bill Janssen wrote:
> As far as I'm concerned, just tying all of
> the program's threads to a single core would be fine, though I imagine
> others would differ.
Which can be done through the OS tools for setting an application's CPU
affinity.
Fixing the Python thread scheduling is only necessary
Nick Coghlan wrote:
> Bill Janssen wrote:
> > Right now, I'm faced with the prospect of Apple's next OS including
> > Python 2.7, and being saddled with the current Python 2.x terrible
> > multicore behavior for the next 5 years or so. We badly need some kind
> > of patch for this in the 2.x bra
Hi,
Le dimanche 16 mai 2010 22:07:06, Nir Aides a écrit :
> *Evolving the GIL into a scheduler*
>
> The problem addressed by the GIL has always been *scheduling* threads to
> the interpreter, not just controlling access to it. The patches by Antoine
> and David essentially evolve the GIL into a s
Bill Janssen wrote:
> Right now, I'm faced with the prospect of Apple's next OS including
> Python 2.7, and being saddled with the current Python 2.x terrible
> multicore behavior for the next 5 years or so. We badly need some kind
> of patch for this in the 2.x branch.
The matter of the GIL seem
Bill Janssen wrote:
> I can find no evidence that the buildbot installation process given on
> the wiki will cause the buildbot slave to be restarted after a reboot of
> the machine. To accomplish this, you should also undertake the work
> described in
>
> http://buildbot.net/trac/wiki/Using
I'm interested in having *something*, but I'm not particularly
interested in the 3.x branch. I expect it to be at least 5 years before
the various Python subsystems I depend on are all ported to 3.x, and I
expect it to be at least that long before I can move onto a version of
OS X that ships with
Hi all,
Here is a second (last?) attempt at getting traction on fixing the GIL (is
it broken?) with BFS (WTF?).
So don't be shy (don't be too rude either) since ignoring counts as down
voting.
Relevant Python issue: http://bugs.python.org/issue7946
*Bottom line first*
I submitted an implementa
I'm running my buildbots in a captive firewalled subnet, and I have to
enumerate all the ports that the buildbot is allowed to open to the
outside world. Right now, I'm getting this error:
ERROR: test_connect (test.test_smtpnet.SmtpSSLTest)
I can find no evidence that the buildbot installation process given on
the wiki will cause the buildbot slave to be restarted after a reboot of
the machine. To accomplish this, you should also undertake the work
described in
http://buildbot.net/trac/wiki/UsingLaunchd
On my Leopard slave, I cr
> A workaround is to just put them in the /etc/hosts file.
That doesn't really help: the test suite also relies on a number of host
names.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
Martin v. Löwis wrote:
> That's a common OSX problem/bug. Processes occasionally lose the ability
> to resolve host names. Various theories float around what's causing this
> (most commonly, people expect that a "controlling terminal" must be
> present); my theory is this:
>
> There is a Mach po
Martin v. Löwis wrote:
> Bill Janssen wrote:
> > parc-leopard-1 (and most of the other builders) are failing the svn
> > checkout with the following error:
> >
> > svn: PROPFIND of '/projects/python/trunk': Could not resolve hostname
> > `svn.python.org': Temporary failure in name resolution
>
Antoine Pitrou wrote:
> On Sun, 16 May 2010 11:55:14 +1000
> Yaniv Aknin wrote:
>> Is the whole notion of a frozendict
>> worthy, given this limitation?
>
> I don't think so. Of course we how have a more general problem:
> - if we choose to implement only equality testing for partials and
> lea
On Sun, 16 May 2010 11:55:14 +1000
Yaniv Aknin wrote:
>
> Is the whole notion of a frozendict
> worthy, given this limitation?
I don't think so. Of course we how have a more general problem:
- if we choose to implement only equality testing for partials and
leave hashing as is, then hashing is
19 matches
Mail list logo
