On 04/20/2011 11:44 AM, Martin Pool wrote:
> On 20 April 2011 19:15, John A Meinel <email address hidden> wrote:
>> How about we land SIGHUP changes, and just go with it for now. We can
>> always open another bug if we need to.
>
> I think you're right: catching sighup is a step forward and will fix
> some cases. What I saw before lead me to believe that when the
> window's killed ssh may also be killed without us getting a chance to
> do anything about it. (We could try to prevent that by eg changing
> process group etc, but that may lead to knock-on problems.)
>
> Probably we should just
> * merge that branch and close this bug
> * reliably release locks server-side over ssh (maybe we do?)
For commands where we can, we do. However, we still have a "write-lock
the remote object because I'm going to do multiple operations" RPC,
where we hand the client a lock token, which it is required to send to
the server for each operation. So the server doesn't know when the last
write action is going to be received. (If ever.)
Again, we try to be stateless, so just having the connection drop
"doesn't count". (Since HTTP wouldn't be able to tell you that.)
> * just cope with stale locks over sftp
>
> I'll have a look at this tomorrow.
>
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/20/2011 11:44 AM, Martin Pool wrote:
> On 20 April 2011 19:15, John A Meinel <email address hidden> wrote:
>> How about we land SIGHUP changes, and just go with it for now. We can
>> always open another bug if we need to.
>
> I think you're right: catching sighup is a step forward and will fix
> some cases. What I saw before lead me to believe that when the
> window's killed ssh may also be killed without us getting a chance to
> do anything about it. (We could try to prevent that by eg changing
> process group etc, but that may lead to knock-on problems.)
>
> Probably we should just
> * merge that branch and close this bug
> * reliably release locks server-side over ssh (maybe we do?)
For commands where we can, we do. However, we still have a "write-lock
the remote object because I'm going to do multiple operations" RPC,
where we hand the client a lock token, which it is required to send to
the server for each operation. So the server doesn't know when the last
write action is going to be received. (If ever.)
Again, we try to be stateless, so just having the connection drop
"doesn't count". (Since HTTP wouldn't be able to tell you that.)
> * just cope with stale locks over sftp
>
> I'll have a look at this tomorrow.
>
John enigmail. mozdev. org/
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAk2 u1m4ACgkQJdeBCY SNAAPBQwCg0Ne30 XzbU1q2J1ekLKvM 6pGz RC0wEforg0LtLdE v1
t8cAoK3YmwSwhYC
=eIgD
-----END PGP SIGNATURE-----