Re: Windows 2003 64 Bit memory utilization?
Related to porting to C++, back when I helped port a large (8+ million line) code base to C++ we had tougher issues than what is faced within memcached, and the product was provably the better for it -- customers noticed the increased level of stability that resulted in addressing a host of latent bugs that C helped to hide. It is not terribly hard to port to C++, but it takes commitment from all parties involved. As for benefits, there were that ended up being resolved as a result. It was a painful few months, but even the die-hard C-fans appreciated the benefits.
Re: Windows 2003 64 Bit memory utilization?
To offer more information related to this, another good place to look, in an unrelated project but cross-platform nonetheless, is ICU. The guys at IBM really made a rock-solid product there; they've addressed every problem you could ever run into when handling cross-platform development issues (even the stdint stuff mentioned above). On the UNIX side there configure scripts are top-notch -- an excellent example on how to do it well. I helped on the Windows side, and with the build system. http://site.icu-project.org/ - Bob On Wed, Nov 4, 2009 at 7:49 AM, Henrik Schröder skro...@gmail.com wrote: On Wed, Nov 4, 2009 at 09:34, David H. google-gro...@wyntrmute.com wrote: Note that I am relying on VC9 here and have no interest in VC8's shortcomings (apologies to anyone who can't afford to upgrade to VC9). That should be fine, I can't imagine the free Visual Studio Express versions not being able to build it, so everyone that wants to can do it. Btw, have you talked to the libevent maintainers? It comes with Visual Studio project files, so I would assume they've run into and solved all the common problems with something that can be built either using configure/make or VS, hopefully also in a way that allows non-windows-aware developers to continue working on the code without breaking anything. /Henrik
Issue with binary protocol spec GET response and key field
Hello, I am working through writing a simple Java UDP client; apparently none of the clients already written support UDP, sigh. The example response in the GET section of the binary protocol shows Key as None, meaning it is omitted in the response. Field(offset) (value) Magic(0): 0x81 Opcode (1): 0x00 Key length (2,3) : 0x Extra length (4): 0x04 Data type(5): 0x00 Status (6,7) : 0x Total body (8-11) : 0x0009 Opaque (12-15): 0x CAS (16-23): 0x0001 Extras : Flags (24-27): 0xdeadbeef Key : None Value(28-32): The textual string World However, in the prior section it states: Response (if found): MUST have extras. MAY have key. MAY have value. Under which conditions will the key be present? Under which conditions will it not. Can someone clarify this in the spec and in this forum? Thank you, Bob
Re: Issue with binary protocol spec GET response and key field
Thank you Dustin. On Thu, Oct 22, 2009 at 4:36 PM, Dustin dsalli...@gmail.com wrote: On Oct 22, 1:24 pm, Robert Buck buck.rober...@gmail.com wrote: However, in the prior section it states: Response (if found): MUST have extras. MAY have key. MAY have value. Under which conditions will the key be present? Under which conditions will it not. Can someone clarify this in the spec and in this forum? A GET/GETQ command will not have a key, but there's a GETK/GETKQ command that is exactly like GET/GETQ, but has a key. I'll add to my notes for things to clarify in there when I get back around to documenting protocol (which should be fairly soon, hopefully answering the questions is good enough for now).
