Re: [Monotone-devel] hang on Win32/MinGW with sync file:

[Stephen Leake]

Matthew Gregan <address@hidden> writes:

> At 2007-12-04T19:33:35-0500, Stephen Leake wrote:
>> Currently, all code outside netxx_pipe.cc uses netxx_pipe.cc. So I don't
>> see what we are gaining by replacing Unix pipes by TCP sockets.
>
> Simplicity.  See Zack's summary below.
>
>> I'm not clear what you mean by "cross platform".
>> 
>> To me, that means "not needing '#ifdef OS'". Clearly, netxx_pipe.cc
>> needs '#ifdef OS'.
>> 
>> netxx_pipe.cc is mostly either WIN32 or Unix; almost none of it is shared.
>
> The current netxx_pipe.cc is a bit of an exception to the rest of the code
> in monotone (except maybe tester.cc, but that's special).  In general, when
> we need to use some platform-specific API, we wrap it up and put appropriate
> implementations in unix/ and win32/.  The user of the wrapped API #includes
> platform.hh and can write general cross-platform code and expect that the
> wrapped call will behave "the same" across platforms.

Right. 

> Also, we're not "fixing" it, we're reworking the code with the intention of
> making it better.  

Ah, ok. I was just trying to fix the Win32 implementation, changing as
little as possible.

> If it turns out that we're really better off using pipes on Unix and
> socket pairs on Win32, fine, but I'd rather that we tried the
> solution that resulted in the least, simplest code first.
>
> At 2007-12-04T16:44:25-0800, Zack Weinberg wrote:
>> Unless I am very confused, the idea is to be able to use the current
>> Unix-specific code (replacing two calls to pipe() with one call to
>> socketpair()) on both Unix and Windows; and the benefit of this is that
>> the low-level Windows API for asynchronous I/O has fundamentally different
>> semantics from the low-level Unix API, and the rest of netxx expects the
>> Unix semantics, which is why we are getting hangs.
>
> Right, that's the plan.

So we are replacing _all_ pipes in Netxx::PipeStream with sockets, and
changing _all_ code that deals with Netxx::PipeStream to expect
sockets. I would not describe that as "using the current Unix-specific
code", but I think I understand.

I'll see if I can make that work.

There are places in netsync that expect a Netxx::PipeStream to have
either two Unix pipes or one Windows named pipe; those will change to
just expect one socket. That will make the code cleaner.

I gather that the point of PipeStream is to let the netsync code
communicate via one object, that internally is either a normal socket
(when started as 'mtn serve'), or stdin/stdout (when started as 'mtn
serve --stdio').

I've created a branch n.v.m.experimental.win32_pipes; it has no
changes in it yet.

-- 
-- Stephe