On Fri, May 20, 2011 at 8:54 AM, Sidu Ponnappa <[email protected]> wrote: > Would it be fair to support Windows only via JRuby? That would make > life much easier for you. > > Best, > Sidu. > http://c42.in
Sorry for the delay, folks - was away from the Internet for the last few days. I've been spiking out ChildProcess (https://github.com/jarib/childprocess; summary: extracted from Selenium gem, a cross-platform library to launch and kill processes) as a platform-relatively-agnostic replacement for CCRB's own hand-rolled process-management code, and according to that's project's implementation JRuby on Windows is the only platform that won't yield a PID after process creation, which might actually create more problems than it solves if we want to be able to kill live builders. Questions to authors: Is there a particular reason why the master Platform.create_child_process method is responsible for creating the pid file, rather than the child builder creating it on launch? Also, there's a reference in the comments that appears to suggest that the builder process tries to hold a lock on its pid file, but that's not the case in the code - it's using a separate file called builder.lock, and the existence of the lock is used by the UI to determine externally whether or not a given builder is running (rather than, say, the builder's own reported status). Why is that the case? Was it a concession to platforms that don't provide pids? It feels to me like both the builder itself and the UI's use of it are crying out for some sort of first-class domain model, but their interactions with the builder are rather different - the UI launches, reads the status of, and (someday) kills builders, builders themselves read and write their own status and respond to kill and build requests. Both require some subset of the same functionality. Right now this stuff is floating around in some combination of Platform, BuilderStatus, BuildBlocker, FileLock, and BuilderStarter, which has been difficult for me to understand and maintain and exacerbates the problem of poor builder status reporting in the UI. Brian _______________________________________________ Cruisecontrolrb-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
