A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2008-April/078379.html below:

[Python-Dev] Tools\buildbot\kill_python.c can't be helping our cause

[Python-Dev] Tools\buildbot\kill_python.c can't be helping our cause"Martin v. Löwis" martin at v.loewis.de
Wed Apr 2 21:29:02 CEST 2008
Trent Nelson wrote:
>>> That'll kill the first python_d.exe instance it finds matching the
>>> given path; given that our buildbots run trunk/release25-maint/py3k
>>> in parallel
>> That's actually not a given: we currently *don't* run multiple builds
>> simultaneously on the same slave.
> 
> I thought the slave lock only applied per branch, not per host?

As the name suggests, it's per slave :-) a slave being the name/password
pair, along with the buildbot.tac file.

The sequencing of builds per builder is not a locking mechanism,
actually; a single builder just won't schedule a new build as long
as a build is already running.

So we have currently three builders per slave, and these are serialized
with the slave lock (hence the occasional long sequences of yellow
"Build nnn": the build starts, tries to acquire the slave lock, which
then a different builder still holds).

Now, on your machine, I understand you also have two slaves running.
They might, in principle, kill each other's python_d.exe processes,
except that the paths will be different there (amd64 vs. not).

Regards,
Martin
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4