Matthew Gregan <[EMAIL PROTECTED]> 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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
