Thanks, Bob. List, Bob and I looked at this together. In general it looks great.
Things I want to do: 1. Ponder the overall strategy for starting up worker threads and communicating with them. It looks odd to me to use the interrupted thread state to communicate whether workers should shut down, but maybe there's nothing better. 2. Check how Scala deals with finding the Java VM to run. I think it's the same way as is used here. Things for you to do, Bob, by my notes: 1. When starting a permutation daemon, give it a cookie to send back on the socket it uses to connect to the worker manager. That way, the manager knows it is talking to a daemon it itself spawned, and not some attacker. 2. When reading stdout and stderr from a spawned thread, make two reader threads instead of just one. This improves the hypothetical case where stdout has a lot of output but stderr has nothing, or vice versa. 3. (maybe) Add a system property for the arguments to pass to Java when starting it. This would be an escape hatch in case copying the current JVM's arguments does not work in some weird context. Also, there's a debate around the office about calling System.gc(). It can speed things up in theory, but it can decrease performance heavily in some contexts. So, it's a bit of a landmine at the best of times. Maybe we should avoid using it until we have a better evidence that it improves things. -Lex --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
