[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] merging branch to allow 'automate stdio' over the n
From: |
Timothy Brownawell |
Subject: |
Re: [Monotone-devel] merging branch to allow 'automate stdio' over the network |
Date: |
Fri, 02 Oct 2009 07:52:59 -0500 |
User-agent: |
Mozilla-Thunderbird 2.0.0.22 (X11/20090701) |
Stephen Leake wrote:
> Thomas Keller <address@hidden> writes:
>> Timothy Brownawell wrote:
>>> This also adds an "automate remote_stdio <address>" command to make
>>> use of these changes, and on the server side a
>>> get_remote_automate_permitted(identity, command, options)
>>> hook which is checked for each automate command received and defaults
>>> to "deny everything".
>> Is the execution of the "l5:stdioe" and "l12:remote_stdioe" commands
>> over stdio / remote_stdio forbidden (this should be the case)?
>
> The documentation says the hook get_remote_automate_permitted returns
> false for everything by default. However, I don't see the default
> implementation anywhere; it's not in std_hooks.lua.
There is no default hook defined, and it's set so that this has the same
effect as having a hook that always returns false.
>> How are network errors handled, i.e. are these encoded properly in
>> stdio or do these come as out-of-band messages?
>
> I think it's out-of-band; see network/session_base.cc
> session_base::do_io. That uses P for netxx exceptions.
Yes, network errors result in a message on stderr and the process dying,
the same as they do for netsync.
>> (I'm trying to revive the out-of-band error handling from the last
>> summit in my spare time because I really want netsync-over-stdio
>> working now... maybe this rather small code part could go into your
>> branch as well?
Not sure how small that would be. I seem to recall PipeCompatibleProbe
not liking to have both stdin/stdout and sockets at the same time (at
least on Windows), and the automate commands and stdio/remote_stdio
machinery aren't set up for forwarding stdin.
>> monotone.texi states that "automate remote_stdio"
>> has a --quiet option to supress some of the netsync output - maybe
>> this could be fixed by that.)
>
> I don't see where --quiet is used.
It's a global option that turns off P() (and tickers. but those aren't
involved here).
>> How are network timeouts handled, i.e. do we automatically reconnect
>> an idled but broken remote_stdio connection?
>
> See netsync.cc call_server; it uses E for a timeout, so it just
> aborts.
>
> In some applications, we want an automate session to tolerate long
> idle times; it's waiting for a user to request something. When
> connected remotely, I think it's ok to not tolerate that. Especially
> for an ssh: connection, which ties up the remote database exclusively.
>
> If the application wants to tolerate long user times, it should be
> prepared to recreate the automate session on its own, rather than
> relying on keeping an idle one open.
>
> This should be mentioned in the info manual.
This should be documented now.
- Re: [Monotone-devel] merging branch to allow 'automate stdio' over the network,
Timothy Brownawell <=