Hacker News Reader

Comment by saurik | Hacker News Reader

FWIW, Microsoft does ship a POSIX implementation called "Subsystem for Unix-based Applications", and it in fact has a working (and I think efficient?) version of fork() (which sounds to be the only thing redis would actually be wanting for once ported to libuv, as this patch does; although, for all I know, libuv doesn't support SUA); that said, it is now deprecated, and will be removed after Windows 8.

View on HN

There is no equivalent to epoll on Windows. There is select (that just happens to get slower when socket's numerical id gets larger). There is also IOCP, which is an ass-backward epoll - a typical Microsoftish contraption that was supposed to be better by being more universal, but ended up being a retarded piece of disaster compared to epoll. I killed a couple of months trying to push and shape IOCP back into the BSD style API, and in the end it worked, but the guts were ugly and the process was utterly unpleasant.

So, no, the "subsystem for unix-based applications" is a no go.

If node.js could make things work on Windows using IOCP then redis could do the same. For starters, they could study the node.js code to compare the epoll version with the IOCP version in order to understand how to use IOCP,

I did say "which sounds to be the only thing redis would actually be wanting for once ported to libuv, as this patch does", a critical aside that you seem to have ignored.

That's because you picked the wrong direction to manage things... check out libuv and how they've built their api in the other direction.

It's not a wrong direction necessarily, it is just a different abstraction level. I did what I did, because of the constraints of the existing codebase. If one abstracts above the socket level, things are getting less hairy, but it also translates into substantially more per-platform code. It also makes the abstraction less flexible.

Reply on news.ycombinator.com