Re: [Monotone-devel] mtn automate stdio - change working directory

[Thomas Keller]

Nathaniel Smith wrote:
> > int count = 0
> > while (still_running() && ++count < 10) {
> >   send_sigterm();
> >   sleep(1);
> > }
> >
> > while (still_running()) send_sigkill();
>
>
> Ew, indeed, that's no fun (and not very portable, either).

Hrm... maybe we've misunderstood each other. Qt comes with generalized 
terminate() and kill() commands which should work on any platform (as 
long as mtn automate stdio reacts on the Windows event WM_CLOSE in 
Windows mtn builds, see [0]), so its more, umm, the weird behaviour / 
implementation of it what sucks. What comes now is Qt interna, just for 
your understanding. To reinit stdio with a new working dir, I basically 
need to:

a) call process.terminate()
b) register a signal/slot for a timer after which I can check if 
process.terminate() succeeded (since the main event loop of Qt has to be 
executed further so I can check process.state() for being set on NotRunning)
c) if in the slot I configured in b) I see "oh, still not terminated", 
either terminate again and check again (after another signal coming from 
the timer), or trigger kill()
d) now, in order to check if kill succeeded, I need to wait again for 
the timer slot
e) if I finally really know that the previous process has been exited, I 
can do process.start("mtn automate stdio") again while giving it the new 
working directory before (of course there is another signal which 
informs me that the new process has been successfully started before I 
can feed him any data)

Now, from outside I just like to have an "init()" or "reinit()" function 
which actually waits until all steps above have been done, but this is 
not possible in Qt, since the best I can do here again is

a) call init() (which returns immediately)
b) configure a slot() which informs me that the initialization is over 
so I can continue...

Now you probably say "why don't you do it that way?" - well, because of 
two things:

1) Why kill a process just for the sake that the process should act on a 
different working directory? Other programs change their working 
directory all the time.
2) Code-wise: Configuring signals/slots in Qt makes the whole app much 
more "wired", if you do it a lot you actually don't see what all these 
things do "connected" like the few lines of pseudo code I gave you in 
the last email do instantly. Signals/Slots are a nice concept in 
general, but in this case this adds much verbosity and wiredness to the 
code. Probably just a Qt problem, of course.

So since I'm in the middle of both things (I asked some Qt guy before 
and he told me "use signals/slots"), and since implementing a working 
dir change on your side seems to have more side effects as I initially 
thought, I probably need to go the ugly code way...

Sorry for this longish answer, I hope I could clear it up a bit.

> I have a third idea to suggest: what if we just added an "exit" or
> "die" or whatever command to "automate"?  Then one could conveniently,
> deterministically, and portably kill off an automate stdio process,
> without all this mess with signals.  Just issue the command, then wait
> for the pipe to be closed instead of a response.
>
> This would obviously be trivial to add on the monotone side of things;
> would it be a complete and convenient solution on your end?

Again, if WM_CLOSE is correctly interpreted on Windows mtn builds as 
equivalent to SIGTERM, Qt should do the trick and there wouldn't be any 
need for such a function. But thanks!

Thomas.

[0] http://doc.trolltech.com/4.1/qprocess.html#terminate