Re: [Monotone-devel] race condition on mtn automate stdio startup

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Am 18.12.2009 10:03, schrieb Stephen Leake:
>> I've just run across a race condition in mtn automate stdio.
>> 
>> During the startup of the command, it checks for various error
>> conditions, such as having a database specified. This can fail if the
>> user is not actually in a workspace:
>> 
>> bash-3.00$ mtn automate stdio
>> mtn: misuse: no database specified
>> 
>> On the other hand, if there are no errors, there is no output; the
>> process is waiting for the next user command:
>> 
>> bash-3.00$ cd gpm
>> bash-3.00$ mtn automate stdio
>> 
>> (killed with C-c)
>> 
>> This is race condition; my Emacs front-end has to wait for "a while"
>> to tell if the mtn process got started ok, before sending the first
>> command.
>
> In general I do the same for guitone (with a timeout of 1000ms), while
> monitoring the stderr stream of the process. If output is generated
> there, I'll immediately kill the process / close the connection.
>
>> I have not looked into possible fixes for this. Perhaps with the new
>> out-of-band facility, there could be a "ready for first command"
>> message at startup?
>
> Actually I've sitting a local change in my workspace which will just do
> so - it will output the interface version right on stdio startup, so
> you'll get
>
> $ mtn automate (remote_)stdio 2>/dev/null
> interface-version: 12.0

Good.

> This system is flexible in a way that more useful information can be
> added to this kind of "headers". Right now only the interface version is
> outputted, but one could think of other (meta-) information later on
> when this is needed.

If it's going to change in the future, we need to keep at least the
first part constant, so current code doesn't break. Maybe just a
simple "ok", followed by whatever.

It might be better to have standard queries for any meta information;
there is mtn automate interface-version
> The one thing I'm struggling right now is to let these headers be also
> properly displayed for remote_stdio (over the network), but I guess in a
> couple of days this should land on mainline.

In this case, I want the first message just to mean "connection to
remote established, ready for command". So the actual message can come
from the local machine; no need for headers over the net.

If we are looking for "remote interface_version", that should be a
stdio query, not a header. So again, a simple "ok" would be good as
the first output.

-- 
-- Stephe