[Top][All Lists]

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

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

From: Stephen Leake
Subject: Re: [Monotone-devel] hang on Win32/MinGW with sync file:
Date: Tue, 04 Dec 2007 19:33:35 -0500
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/22.1 (windows-nt)

Matthew Gregan <address@hidden> writes:

>> Note that dumb_socketpair is _not_ actually cross-platform; it has the
>> same #ifdef WIN32 style that currently has, and the WIN32
>> version has an extra parameter that is important. Apparently 'socketpair'
>> is implemented on some/most "unix" platforms, but not on Win32?
> Right, that code is an implementation of socketpair() for Windows because it
> is not provided by the Windows socket API.  Cross platform refers to the
> rest of the code--all platforms can use socketpair() and almost all of the
> rest of the code can be shared between platforms (except for process
> creation, but we probably already have sufficient wrappers for these in the
> $platform/ directories already).

Currently, all code outside uses So I
don't see what we are gaining by replacing Unix pipes by TCP sockets.

>> I don't think there's any reason to change the non-WIN32 parts of
>> Although we should split into
>> win32/, unix/
> We try to keep as much code as possible cross platform. 

I'm not clear what you mean by "cross platform".

To me, that means "not needing '#ifdef OS'". Clearly,
needs '#ifdef OS'.

> I'd prefer to keep the code shared in the top level is mostly either WIN32 or Unix; almost none of it is shared.

> and just have any OS-specific wrappers pushed down into the
> $platform/ directories. In this case, that would be the
> dumb_socketpair code and possibly some extension to our existing
> process creation code.
>> So it would be cleaner to copy the dumb_socketpair implementation idea,
>> directly in, rather than using dumb_socketpair as is. That
>> could work around the license issue as well.
> I'd prefer to ask Nathan about the license and then include the file
> directly. 
> The Win32 specific code can go in win32/socketpair.c. 

The Win32 specific code implementing sockets is less complex than the
current WIN32 specific code in So the minimal change to
the current system is to just replace that.

> The unix/ implementation can just call the real socketpair()
> directly like the !WIN32 case in socketpair.c does.

Why should we change the unix part of It's not broken;
let's not "fix" it.

-- Stephe

reply via email to

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