<div class="gmail_quote">On Mon, Sep 17, 2012 at 5:28 PM, Gerard Gorman <span dir="ltr"><<a href="mailto:g.gorman@imperial.ac.uk" target="_blank">g.gorman@imperial.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1rg">So if I understand you correctly I should start a python session (handy<br>
since buildbot is all python), import in your test harness and then<br>
start calling tests. If this is the case (kick it back if I've<br>
misunderstood) then iterating through a list of tests would seem to be<br>
the way to go. This would give maximum flexibility to filter tests into<br>
categories (for example MPI tests might need to be handled differently<br>
than serial tests).</div></blockquote><div><br></div><div>So I'm planning to provide a rich API for filtering/selection. I see that as a key motivation for doing this system in the first place. Of course you can run a query and get back a list of test objects, but you could also just say "run everything matching this query and report the result". In that case, you would get called back with each completed test.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1rg"> This also would give plenty of flexibility to do<br>
whatever with the output - eg might write out all<br>
-log_summary/stdout/stderr to buildbot log in case of error and drop<br>
otherwise.<br></div></blockquote><div><br></div><div>The callback will be provided with all that information.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1rg">
Have you a plan for how to handle machine specific ways to run<br>
mpiexec/queueing etc? Are you going to recycle methods from the<br>
BuildSystem or will there be a mechanism to supply my own mpiexec or<br>
batch queueing harness?<br></div></blockquote><div><br></div><div>There will be a runner interface. You'll be able to write a plugin to run tests using some custom submission system. It will report back return code, stderr, and stdout.</div>
<div><br></div><div>In terms of Python library dependencies, I would really like to use gevent. It's portable and provides a very good parallel abstraction. It does use a (tiny) C extension module. Is that dependency going to be a deal-breaker?</div>
<div><br></div><div>The alternatives, assuming we want parallel test execution and (eventually) parallel configure, are</div><div><br></div><div>1. yield-based coroutines: less convenient interface, mostly because we can't yield from subroutines (prior to python-3.3)</div>
<div><br></div><div>2. event-driven callbacks: less convenient because logic has to be refactored. Also less useful stack traces</div><div><br></div><div>3. subprocesses for everything: can have messy tear-down, more work to move data between processes, still need to refactor for callbacks because each suspended context cannot be a process.</div>
<div><br></div><div><br></div><div>Since the testing dependency graph can (and generally will) be constructed without needing to do anything asynchronously, the gevent issues above are not nearly as acute. We could use a basic thread pool and have each thread take items out of the queue. The GIL is released when they do IO so this is fine. For configure, the dependency graph is potentially dynamic, in which case a system that can manage many suspended contexts would be ideal. I've done simple implementations with several systems and the gevent code is both cleanest and fastest so that's what I've started with.</div>
</div>