On 13 February 2012 23:44, Szczepan Faber <[email protected]> wrote:
> Yesterday me & Daz talked a bit about the daemon matching and honoring > gradle.properties settings for the regular gradle. I've slept on it and > have some feedback. Sorry if my email is not verbose enough - I'm cutting > the story short. > > The current approach we aim for is: > > -When no-daemon build starts, we parse the gradle.properties. If the > settings match the current process we happily continue. If the settings > don't match the current process we execute the build in a single-life > daemon. > I've got the first bit of this done. Now, when we don't find a matching daemon process and we create a new one, we _always_ use the created process. It is no longer possible for another client to grab 'our' daemon process before us, and there's no chance that 'our' daemon will be excluded because it doesn't satisfy our requirements. It will now be trivial to add support for forking a single-use daemon for any build: we just need to a) bypass the search for existing daemons and b) ensure the created process doesn't live beyond our build. > I'm leaning towards a simpler approach, e.g. always spawn a child process > when gradle.properties contains process-sensitive settings because: > > 1. It avoids tricky process matching. Java's getInputArguments() is not > reliable enough for strict matching: extra vm options of some platforms, > rubbish options when some sys. properties are quoted with spaces, and > possibly other problems as they usually come in clusters. > > 2. The reason someone configures java settings in gradle.properties is > because he wants something different than the default. So, in majority of > cases the client process will not match the 'desired' criteria and we will > spawn the child process, anyway. So, why do we want to complicate the > algorithm for a quite unusual use case? Also the more process and java > configurability we introduce to the gradle.properties, the less likely it > will be that the client process matches the desired context. > > 3. It feels like a natural step towards default daemon and (a bit of a > song of future) native client. I.e. moving away from "in-process or daemon" > mode towards "short-lived daemon or long-lived daemon" mode. > I tend to like this approach. "Matching" the current process with the requirements is going to be tricky indeed. I also like the idea of changing the 'daemon matching' so that we don't compare _everything_ about the daemon process, but only those things that we explicitly specified at startup. So rather than rely on the daemon to calculate it's settings, we'd explicitly specify them when creating the daemon (so I guess we'd create a daemon with certain args, then tell the daemon "by the way, this is how you were started"). We could then look for a daemon that was started in the same way we need one started, rather than looking for a daemon who is running the way we want one running. A couple of issues: 1) How do we determine the startup settings for a foreground daemon? 2) If we want to match the regular gradle process to avoid forking, how do we determine the startup settings of the gradle process? -- Darrell (Daz) DeBoer Principal Engineer, Gradleware http://www.gradleware.com
