monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Freeze on Windows using ssh transport


From: Nathaniel Smith
Subject: Re: [Monotone-devel] Freeze on Windows using ssh transport
Date: Tue, 20 Feb 2007 14:58:56 -0800
User-agent: Mutt/1.5.13 (2006-08-11)

On Wed, Feb 21, 2007 at 07:03:23AM +1100, Daniel Carosone wrote:
> The ssh:// db access method is really not meant for multiuser work;
> there's no support for multiple concurrent 'clients' accessing the
> same server db in parallel, other than via netsync.  So multiple
> concurrent users will trip over db locking issues.
> 
> The first -- unlikely -- possibility is that you're tripping over this
> but in some odd way that isn't making the db locking error obvious.  I
> doubt that.
> 
> The second is that there appears to still be some cases where netsync
> gets wedged.  The usual workaround is to try either just pulling or
> pushing (rather than sync) or to change the selection set (by syncing
> just a subset of branches, or by committing some more local revs).  We
> thought we had killed the last of these some time ago, but we hit
> another instance during the summit, in that case with nearly-empty
> databases (ie, containing only a handful or revs).

A third possibility is that there are issues with the
talk-to-child-process code on windows, which is utterly nasty.  It
took ages and ages to get that code working at all, it's still
very difficult to understand, and there are still intermittent
failures in the test suite that no-one has managed to reliably
reproduce, where it just blocks forever waiting on the child
process... (our best guess so far is that it might have something to
do with windows having a broken buffering model for named pipes).

We were discussing a possible rewrite of this code just yesterday on
IRC:
  http://colabti.de/irclogger/irclogger_log/monotone?date=2007-02-18,Sun#l105
The trick is pretty straightforward: instead of using named pipes to
talk to the child, just create two sockets, bind one to a port on
localhost, and then connect to yourself over the loopback interface.
This is baroque, but if you do it right then you get a windows socket
handle that you can use as a child's stdin/stdout, and that you can
select() on.  On unix, of course, you can just call socketpair() to
get the same thing.  This would probably reduce the size of our child
process handling code by a factor of 4 and have less bizarre bugs
too...

-- Nathaniel

-- 
Damn the Solar System.  Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better one myself.
  -- Lord Jeffrey




reply via email to

[Prev in Thread] Current Thread [Next in Thread]