Re: windows port of C API
Sounds reasonable. If we really want to be serious about it we should update hudson (or add buildbot) to build/test on cygwin/windows in addition to our current ubuntu build. But we can do it by hand to start with. Patrick On Tue, Aug 31, 2010 at 11:06 AM, Ben Collins wrote: > I agree that avoiding the multiple build systems would be nice. > Unfortunately, though, windows is an animal unto itself. I would > be hesitant to change the whole build system over to cmake just for the > ideal situation that there be one build system for all platforms. I have > seen projects that maintain the win32 build separate from the *nix builds, > and this does not seem to be too onerous. I'm flexible, but will probably > in the end use the same tools to build as I do now. > > One remaining critical issue is the zookeeper_close() call while the client > is in the CONNECTED state. Even in the single-threaded setup this call > blocks when connected instead of using zookeeper_interest() and a callback, > as seems appropriate. The current code can cause an infinite loop. For > this port to be serious, we would need this cleaned up. > > > On Tue, Aug 31, 2010 at 1:09 PM, Patrick Hunt wrote: > >> Hi Ben, that's great!. There has been some interest in this, however I'm >> not aware that anyone has done a port. >> >> Here's how to contrib: >> http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute >> basically you would create a JIRA and attach your patch against latest >> trunk svn. The committers will review and provide feedback. >> >> It would be great to not have to manage multiple build systems for the c >> code. Should we switch to something like cmake instead of autotools? Or will >> that work for you (win/cygwin/unix based build I mean). >> >> Patrick >> >> >> On Mon, Aug 30, 2010 at 2:00 PM, Ben Collins < >> ben.coll...@foundationdb.com> wrote: >> >>> I have a working win32 port of the C API, not depending on Cygwin, that >>> supports the "single-threaded" model of network interaction. It compiles >>> in >>> Visual Studio 2010 and works on 64 bit Windows 7. There are know >>> issues, >>> and it is in it's initial stages; but it has been successfully used >>> against >>> the java server. >>> >>> I am happy to provide patches, but would like any pointers to efforts >>> already undertaken in this area, or folks to communicate with about this. >>> >>> Thanks, >>> -- >>> Ben >>> >> >> > > > -- > Ben > >
Re: windows port of C API
I agree that avoiding the multiple build systems would be nice. Unfortunately, though, windows is an animal unto itself. I would be hesitant to change the whole build system over to cmake just for the ideal situation that there be one build system for all platforms. I have seen projects that maintain the win32 build separate from the *nix builds, and this does not seem to be too onerous. I'm flexible, but will probably in the end use the same tools to build as I do now. One remaining critical issue is the zookeeper_close() call while the client is in the CONNECTED state. Even in the single-threaded setup this call blocks when connected instead of using zookeeper_interest() and a callback, as seems appropriate. The current code can cause an infinite loop. For this port to be serious, we would need this cleaned up. On Tue, Aug 31, 2010 at 1:09 PM, Patrick Hunt wrote: > Hi Ben, that's great!. There has been some interest in this, however I'm > not aware that anyone has done a port. > > Here's how to contrib: > http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute > basically you would create a JIRA and attach your patch against latest > trunk svn. The committers will review and provide feedback. > > It would be great to not have to manage multiple build systems for the c > code. Should we switch to something like cmake instead of autotools? Or will > that work for you (win/cygwin/unix based build I mean). > > Patrick > > > On Mon, Aug 30, 2010 at 2:00 PM, Ben Collins > wrote: > >> I have a working win32 port of the C API, not depending on Cygwin, that >> supports the "single-threaded" model of network interaction. It compiles >> in >> Visual Studio 2010 and works on 64 bit Windows 7. There are know issues, >> and it is in it's initial stages; but it has been successfully used >> against >> the java server. >> >> I am happy to provide patches, but would like any pointers to efforts >> already undertaken in this area, or folks to communicate with about this. >> >> Thanks, >> -- >> Ben >> > > -- Ben
Re: windows port of C API
Hi Ben, that's great!. There has been some interest in this, however I'm not aware that anyone has done a port. Here's how to contrib: http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute basically you would create a JIRA and attach your patch against latest trunk svn. The committers will review and provide feedback. It would be great to not have to manage multiple build systems for the c code. Should we switch to something like cmake instead of autotools? Or will that work for you (win/cygwin/unix based build I mean). Patrick On Mon, Aug 30, 2010 at 2:00 PM, Ben Collins wrote: > I have a working win32 port of the C API, not depending on Cygwin, that > supports the "single-threaded" model of network interaction. It compiles > in > Visual Studio 2010 and works on 64 bit Windows 7. There are know issues, > and it is in it's initial stages; but it has been successfully used against > the java server. > > I am happy to provide patches, but would like any pointers to efforts > already undertaken in this area, or folks to communicate with about this. > > Thanks, > -- > Ben >
Re: windows port of C API
Hi Ben, that's great!. There has been some interest in this, however I'm not aware that anyone has done a port. Here's how to contrib: http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute basically you would create a JIRA and attach your patch against latest trunk svn. The committers will review and provide feedback. It would be great to not have to manage multiple build systems for the c code. Should we switch to something like cmake instead of autotools? Or will that work for you (win/cygwin/unix based build I mean). Patrick On Mon, Aug 30, 2010 at 2:00 PM, Ben Collins wrote: > I have a working win32 port of the C API, not depending on Cygwin, that > supports the "single-threaded" model of network interaction. It compiles > in > Visual Studio 2010 and works on 64 bit Windows 7. There are know issues, > and it is in it's initial stages; but it has been successfully used against > the java server. > > I am happy to provide patches, but would like any pointers to efforts > already undertaken in this area, or folks to communicate with about this. > > Thanks, > -- > Ben >
RE: windows port of C API
I would be very interested to see any work already done and provide feedback, we need such a port and were planning on writing one ourselves. C -Original Message- From: Ben Collins [mailto:ben.coll...@foundationdb.com] Sent: Monday, August 30, 2010 5:01 PM To: zookeeper-dev@hadoop.apache.org Subject: windows port of C API I have a working win32 port of the C API, not depending on Cygwin, that supports the "single-threaded" model of network interaction. It compiles in Visual Studio 2010 and works on 64 bit Windows 7. There are know issues, and it is in it's initial stages; but it has been successfully used against the java server. I am happy to provide patches, but would like any pointers to efforts already undertaken in this area, or folks to communicate with about this. Thanks, -- Ben
Re: windows port of C API
Ben Collins writes: > > I have a working win32 port of the C API, not depending on Cygwin, that > supports the "single-threaded" model of network interaction. It compiles in > Visual Studio 2010 and works on 64 bit Windows 7. There are know issues, > and it is in it's initial stages; but it has been successfully used against > the java server. > > I am happy to provide patches, but would like any pointers to efforts > already undertaken in this area, or folks to communicate with about this. > > Thanks, Ben, is it possible to get that port? We'd like to try it out in our environment. Single-threaded is ok in the first step. Of course we'll contribute the enhancements if we can make some. Best regards Jan