NRWT spins the HTTP server down and back up an extra time when retrying a failed HTTP test when Requested by abarth on #webkit.
I'm not sure if you can do anything about this and still drop the http lock aggressively (in order to enable concurrent NRWT runs to share the http lock). Two possible options are to not drop the lock if there is a failure (assume that retrying the test takes precedence over sharing the machine), or to provide a command line flag to toggle whether we need locks at all (and just start and stop the server at the beginning/end if you don't). But starting and stopping should be pretty fast ... is this causing some other problem, or is it just slow?
I suspect an easy solution is to just keep holding the lock when all the tests we've been asked to run are HTTP tests. That case will basically only occur when running NRWT interactively and when the user has selected a small subset of tests to run.
at least now (and I think this was probably the case even when this bug was filed), the code that manages retrying on failures is separate from the code that actually starts and stops the servers (manager.py vs. layout_test_runner.py). So, we'd have to rework the layering to add a dont_stop_the_server_if_there_are_failures and then a _no_need_to_start_the_server_its_already_running flag on those interfaces. This doesn't really seem worth it to me, but I'm not sure if this is really annoying anyone else? Thoughts?