Andreas Gudian sent me a private email about this, but since this is some of the awesomest stuff I've seen in a long while, I simply have to share and invite the rest of you to participate in this discussion ;)
The patch provides reusable forks for surefire (we already support parallel forks, now you can on-the fly add more tests to each fork too, possibly dynamically scheduling to the first free fork). I have for the last year or two been refactoring surefire to reduce complexity enough to make this an option, and I'm really happy someone just implemented this without further ado ;) His work is currently located at https://github.com/agudian/maven-surefire/tree/fm-onceperthread There is at least one thing I'd like to discuss with all of you, and this regards concurrency ;) The current code views each forked testrunner process as "server" and the surefire plugin has a single ForkClient for each server that I originally intended be a front-end for all comms to that server. The thing I wonder most about is that Andreas's code also maintains a queue of tests within each forked server (=test runner). When the queue runs empty, it requests more tests, which are provided from the ForkClient within the plugin. In my mind I had always envisioned that the server would run a single test, respond back to the plugin. The plugin would send a new test or "quit" back to the fork. (As a side note, this fature could probably be adapted to re-use the forked process across modules in a reactor build too; which is a really interesting optimalization especially if you can amend classpath when possible) Now the thing is from a classical textbook perspective my solution is far inferior to what Andreas has implemented. This is one of those areas I believe threading blows classical wisdom right out of the water and the round-trip cost becomes irellevant for most practical use cases. I'm wondering if Andreas has tried to see if there's any measurable difference between queue inside fork and not. Additionally I would have /enjoyed/ to make the "controller" concept a bit more explicit so we could have a clear pattern of a single ForkController object owning one or more ForkClients and some tasks to be done. I'm thinking that the "ForkStarter" class could probably instantiate a "ForkController" and hand all the created ForkClients over to that. I'm still cheweing on the impressions from your excellent code, but I have this feeling that would improve the awesomeness even further. It's definitely the awesomest I've seen for quite some time. The patch is still going to take me some time to absorb and there might be a few detils to sort out, I sincerely hope others will look at it too ;) Kristian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
