Ok, I'm fine with holding off on it for now.

Any reason not to move it higher, before the pipe is even created? Would
make it easier to abort.

Lastly, (and separately) are there any state keys that have been added or
changed that will be problematic given upgraded processes will have nil
values for them?

On Tuesday, May 27, 2014, Andreas Fuchs <notifications@github.com> wrote:

> In lib/einhorn/command.rb:
>
> > @@ -225,12 +225,25 @@ def self.reload
> >        ENV.clear
> >        ENV.update(Einhorn::TransientState.environ)
> >
> > +      upgrade_sentinel = fork do
>
> Yeah, I'll believe that it would be nice to have that ability to reason.
> Right now, though, this means having to rewrite the entire upgrading flow
> into something that resembles callbacks (search for occurrences of the
> Einhorn::Command::reload method call). This involves a bit too much
> surgery for my tastes today. /:
>
> Check out the way everything is currently factored, I think this might be
> at the right set of tradeoffs.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/stripe/einhorn/pull/37/files#r13092497>
> .
>


-- 
Sent from mobile