<html>#536: Don't overload machines while building
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Erik Schnetter</td></tr>
<tr><td style='text-align:right'> Status:</td><td>wontfix</td></tr>
<tr><td style='text-align:right'>Milestone:</td><td></td></tr>
<tr><td style='text-align:right'> Version:</td><td></td></tr>
<tr><td style='text-align:right'> Type:</td><td>enhancement</td></tr>
<tr><td style='text-align:right'> Priority:</td><td>minor</td></tr>
<tr><td style='text-align:right'>Component:</td><td>SimFactory</td></tr>
</table>
<p>Changes (by Roland Haas):</p>
<p><table>
<tr><td>status:</td><td>wontfix (was new)</td></tr>
</table></p>
<p>Certain machines are easily overloaded by building Cactus; building multiple configurations at the same time is not possible there. For example, LONI does not have sufficient compiler licences, or Orca (Sharcnet) does not allow sufficiently many user processes. On LONI, things will be very slow (also for other users), on Orca building will fail with strange error messages.</p>
<p>I suggest a mechanism that automatically serialises building Cactus configuration on certain sets of machines. Ideally, one would extend the "make -j" mechanism for this; practically, an implementation via locks may be simpler. Note that this has to work for sets of machines, not just single machines.</p>
<p><strong>Keyword:</strong></p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/536/dont-overload-machines-while-building'>https://bitbucket.org/einsteintoolkit/tickets/issues/536/dont-overload-machines-while-building</a></p>
</html>