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

[Nathaniel Smith]

On Mon, May 22, 2006 at 11:53:43PM +0200, Thomas Keller wrote:
> During my work for guitone I noticed that I eventually need to kill and
> restart the mtn automate stdio process, because when I change the
> workspace to some other directory, the working directory of the created
> and running process still points to the original working directory and
> thus most stdio commands return old data. Now, killing, recreating and
> starting processes in Qt requires a lot of, let me call it "fancy", code
> as it involves sending and handling signals at many places. Something
> easy like (pseudo code)
> 
> 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).

> to make sure a previous process has been killed and we're reading to
> create a new one isn't available/possible there. So, now I thought "why
> kill the process at all I could make him change his working directory?"
> - something like
> 
> l9changedir:16/new/working/dire

This makes me nervous -- one of monotone's simplifying assumptions is
that the directory never changes at runtime.  For instance, this makes
some basic functions (like file_path_external), that are currently
entirely deterministic (same input always give same output), no longer
so.  There is code right now to make sure that any accidental use that
violated this constraint is flagged immediately as a bug; that code
would have to be removed.  Etc.

> Another possibility would be to parametricize the commands, for example
> "inventory" to act on a different working directory:
> 
> l9inventory:16/new/working/dire
> 
> What do you think? Personally, the first thing (changedir) sounds like
> less work. I'm up for trying to implement it if somebody tells me that
> this is a reasonable idea, well, if not, bash me for being ignorant, a
> newbie, stupid and all =)

Aside from being somewhat annoying to deal with, like you say, this
would be very hard to implement -- the existing code doesn't have any
way to pass this information around, so everything that touched the
workspace would have to change.

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?

-- Nathaniel

-- 
"The problem...is that sets have a very limited range of
activities -- they can't carry pianos, for example, nor drink
beer."