2012/11/7 Kristian Rosenvold <[email protected]>: > 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)
It got lost somewhere, but the reason /why/ I dislike the queue is because it makes the forked server asynchronous and multithreaded whereas I originally figured it could be single-threaded (and synchronous) like today. Of course,if it proves to be significantly better I'm all cool, but the increased cost in complexity needs to justification since I generally find this kind of latency-optimization to be useless in threaded environments. Kristian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
