On Nov 4, 1:53 am, dormando <[email protected]> wrote: > [...] > Have you looked through our current win32 branch? There's one on github > that's had a few cleanups since (in dustin's repo..maybe a new one in > patrick's?).
No, but if that's a good place to start, I will check it out. > [...] > I think it'd be helpful if you could enumerate some real problems that > come out of relying on mingw (note that we're not going down the cygwin > route)? Most of the problem is political rather than technical. The project I want to use memcached for requires the most performance that we can reasonably squeeze out of a caching solution. I am making the case that a shared off-box cache is going to be a better long-term scaling solution than our current on-box caches (better hardware utilization, among other project-specific features), but I have to overcome a certain amount of resistance associated with the momentum of a legacy product, not to mention sell what is essentially a Linux product to a Windows shop. So even though a 32-bit MinGW build with many instances should work just fine in theory, it is something of a non-starter from a political perspective. Similarly, any kind of library-based abstraction layer (especially going through a DLL, etc.) will be perceived as additional cost that will make my case all the more difficult to sell (the current cache uses shared memory for IPC, and the size of data per request is non-trivial...yes, I'm pitting GigE latency/bandwidth vs. shared memory). The main alternative at this point is Microsoft Velocity, and I'd much rather not go down that route if I can avoid it. I know that memcached is a solid solution, because I've seen it work at scale, but this was in a Linux shop. Now I want it to work in a Windows shop, and its status as a Linux-"ported"-to-Windows product is not winning many points. If I can make a native Windows version, I think I can make a compelling case. But from a support perspective, nobody here will want to maintain a MinGW build environment, as the focus is on consolidation of technologies, not diversification. They especially will not want to support a new compiler (which gcc is relative to VC9...just getting everyone to upgrade from VC7 to 9 is a major project). I understand that none of these problems are concerns of you as maintainers of this product. However, I would not be surprised if there were many other users out there who would dearly love a native Windows port and have some of the same political challenges to deal with that I do (not having to use gcc, even though we know that it's also a better product in many respects). > It'd nice for us since we can actually run these binaries and > cross-compile them. Makes it a lot easier to run the test suite, for > instance. Folks like me can also easily run local cross compilers and > track down build issues without resorting to a shared windows machine in a > VM somewhere. Those are valid concerns. If I were to create a Windows port, I would want to maintain test parity and I could provide the Windows build & test environment if necessary. > If we're going to run into real troubles from using mingw instead of > relying on "native" for what few system calls memcached actually makes, > we'd love to know about it sooner than later. I don't think there are any strong technical challenges, as people already use the MinGW build successfully. The main technical question is, what abstraction penalty is being paid by going through the compatibility layer (I have no idea). Even if it is trivial, there is also the fact that MinGW is not a native build environment for most Windows shops (this is the bigger problem, and likely a showstopper for my shop). Also, there will necessarily be fewer opportunities for tweaking and optimization when going through the MinGW API. Just check MSDN for how Windows handles mutexes to see how different pthreads and Win32 threads are. Yes, they can be made to behave in essentially equivalent ways, but that doesn't guarantee that it's the best or fastest way to do things (and why are you guys using C99 if you don't want memcached to be wickedly fast?). > > I am not interested in making a one-click Windows installer for > > memcached, or dirtying the codebase with such tangential issues > > (unless they were sequestered in an appropriate subdirectory). > > However, I am only going to invest the effort in porting it if I know > > that the Windows port will benefit from future changes. > > It would be highly appreciated if you could relax a little on your > requirements and work with us. I'm not saying VC9's not out of the > question either, but you'll see how much work it would require? Yes, but I'm volunteering to do most of it. Why? Because if I get a successful native Win64 build running in my project, then I will have a strong, vested interested in making sure the Windows port stays current. From my perspective, I'm taking a calculated risk on a strategic investment. From what I can tell, the worst outcome for you is Yet Another Windows Port that perhaps does not get maintained, or simply continuation of the status quo (that's what source control is for, after all, no?). > We're not asking about making an installer at all.. I imagine someone at > northscale will bother with that. I can't be arsed either, especially > since I'm not paid to make it work ;) My point was simply that I'm not interested in turning memcached into a full-fledged Windows app, since it is by its nature a Linux product. I prefer Linux myself, and I would love to acquire some Linux machines, run it on there and call it a day. But I don't get to pick the platform and I don't choose the support burden for operations, so I am constrained to find a solution which runs on Windows and fully exploits our 64-bit hardware. Dave
