Comment by wfunction

13 years ago

> The problem with Windows is that there isn't any such super-select, unlike on Linux (see epoll, signalfd, timerfd...)

> I can't really use IOCP, because I need keep things reasonably portable

LOL!

You outright dismiss the solution because it isn't "portable". What does "portable" mean here? Portable in a particular platform?!

Portable between what exactly? IOCP has been there since Windows NT 3.51 -- it's "portable" between the Windows-es.

Your epoll, signalfd, timerfd, etc. are Linux functions They're "portable" between the Linux-es.

i.e. The "portable" solutions you like are just as non-portable as the "non-portable" solutions you outright dismiss, making Microsoft's Windows designers look like idiots.

You're never going to find a solution while considering the Linux platform to be the "portable platform" and Windows to be the weird kid on the block.

Sadly, you're not the only person who thinks like this.

4 comments

wfunction

Reply
huhtenberg  13 years ago

A scalable variation of BSD socket API is supported by every major OS with a sole exception of Windows. It's an abstraction that is both simpler and more universal than IOCP model, not to mention that it also predates it by a decade.

So "LOL!" yourself, bud.

  • wfunction  13 years ago

    > A scalable variation of BSD socket API is supported by every major OS with a sole exception of Windows

    It's funny, you mention "epoll, signalfd, timerfd" as an example of a portable API, and then when I point out they're Linux APIs, you suddenly start talking about "a scalable variation" of the BSD sockets API. As for your "scalable variation of BSD sockets API", why don't you tell us the name so we know what you're referring to? Are you talking about Kqueue for example, or something else?

    > an abstraction that is both simpler

    I/O completion ports are just read-write queues... you ReadFile(), and when it's done, an item goes into the queue. (You can insert your own tasks into the queue, too, if you want.) Now just pop off the next item in the queue and off goes your thread. What part of that was so complex compared to your portable API (which for some reason you didn't feel was appropriate to mention the name of)?

    > and more universal

    Can't reply to it without knowing what "scalable variation" you're referring to, and why you didn't actually mention it as an example of portability when you were actually talking about the subject. Is portability actually a concern for you or no? (If it is, why did you bring up non-portable examples?!)