4 ms·

> WaitForMultipleObjects as a kind of super-select to wait on anything Except for the 64 handle limit, which makes it largely useless for anything that involve

> WaitForMultipleObjects as a kind of super-select to wait on anything Except for the 64 handle limit, which makes it largely useless for anything that involves server applications where the number of handles grows with the number of clients. So then you'd spawn "worker" threads, each handling just 64 handles. And that's exactly where your code starts to go sour - you are forced to add fluff the sole purpose of which is to work around API limitations. What good is the super-select if I need cruft to actually use it in the app? And don't get me started on the clusterfuck of the API that is IOCP. > Yes, Windows gets a lot wrong, but it gets a lot right. Oh, no, it doesn't. Specifically, what Windows does not get is that it's other developers that are using its services and APIs, not just MSSQL team that can peek at the source code and cook up a magic combination of function arguments that does not return undocumented 0x8Fuck0ff. I have coded extensively for both Linux and Windows, including drivers and various kernel components, and while Windows may get things right at the conceptual level, using what they end up implemented as is an inferior and painful experience.

acqq 14y ago
As far as I see you had a contact with Win API but you haven't understood enough, based on your complaints. Moreover, why do you mention "MySQL" as the team with the access to kernel sources?
- huhtenberg 14y ago
  You see wrong. And I meant MSSQL, of course. Fixed.
  - acqq 14y ago
    Can you than please give a technical reason for you to insist on waiting on more than 64 threads in a single API call, having simply too many threads for good performance anyway when IO Completion Ports could be used instead?
    - ambrop7 14y ago
      He probably doesn't have 64 threads, but he may have much more than 64 files or sockets. After all, the response was to the statement that "WaitForMultipleObjects as a kind of super-select to wait on anything". It clearly isn't, with this arbitrary limitation. The problem with Windows is that there isn't any such super-select, unlike on Linux (see epoll, signalfd, timerfd...). You should take a look at my SO answer which lists six different ways to use sockets in Windows: http://stackoverflow.com/questions/11830839/when-using-iocp-should-i-set-wsaoverlappeds-hevent-to-null-or-to-a-valid-handl/11831450#11831450 http://stackoverflow.com/questions/11830839/when-using-iocp-...
      - acqq 14y ago
        Whatever he has more, waitfor is not the optimal way on Windows for that so it's still a complaint that round holes on Win32 are poor fit for his cubes. First choosing tools then complaining that they don't fit to some goal is typical for beginners.
        huhtenberg 14y ago
        Do tell me, oh, enlightened one, what I should be using if I have 10K idle network connections and I can't really use IOCP, because I need keep things reasonably portable. That's not even considering that IOCP is a great example of premature optimization at cost of clarity and simplicity. It tries to solve a problem that I don't have and it doesn't offer a simpler solution that would just do. It is not a "hole" for my square peg, it's a freaking snowflake. And expecting a modern OS to have an uncomplicated O(1) API for monitoring sockets is clearly too much to ask.
        ambrop7 14y ago
        It's possible to abstract IOCP and non-blocking sockets into a single interface with reasonable efficiency. For example: - To send data, user calls Socket::send(const char *data, size_t length). This starts sending the given data; the buffer must remain available while data is being sent. IOCP implementation will initiate I/O using WSASend() or similar. - When send operation is complete, the socket implementation calls a Done() callback of the user, and from that point on, the user is allowed to call Socket::send() again. With proper implementation, send() can directly be called from the callback. This interface is very easy to implement on Linux. But on Windows there's a complication, because it's non-trivial to just stop an IOCP I/O operation that is in progress, in case you decide you don't need the socket any more and want to red rid of it NOW. If you just forget about it, there could be a crash when you release your buffer but Windows is still using it. A simple solution is to CancelIo() the socket and do blocking GetQueuedCompletionStatus()s until you get an event inidicating the completion of the pending I/O operation - taking care to queue up any unrelated results you may have gotten, for later processing. However, a more efficient solution is to use reference counting or similar with your buffers, so they only get released when Windows is done with them. I didn't say it's easy, but it's possible.
- deleted 14y ago
  [deleted]
wfunction 14y ago
> not just MSSQL team that can peek at the source code and cook up a magic combination of function arguments that does not return undocumented Don't leave us hanging... what examples are you referring to?
- shubb 14y ago
  One problem that the WINE project (windows emulator for unix)has is that windows is full of undocumented APIs, some of which might be really quite useful, which are used by windows internal developers. For WINE, if you are going to write an emulator that runs Microsoft code (like the .net framework, or notepad.exe), you need to find the correct behavior of these undocumented APIs by trial and error. For a developer on Windows, it is perhaps frustrating that MS identifies and solves problems with it's platform, but doesn't publicly release these solutions to you. I work for some random company that makes an SDK, although I mostly make products using it. Many of our best features are hidden - we don't ship the header files with the SDK, but the symbols are there in the binaries. Someone doesn't think they are useful enough to justify the testing expense for a full release. I guess MS have the same thing.
  - mikevm 14y ago
    >One problem that the WINE project (windows emulator for unix) Wine Is Not an Emulator.
    - shubb 14y ago
      @Mike - Yes, that is true enough.
    - fnordfnordfnord 14y ago
      What shall we call WINE then? A "pretender"? I'm serious btw. I've never seen a good concise explanation of the way WINE works in comparison to say, an emulator. I have a fairly good idea myself, but I wouldn't want to have to give more than a very brief talk over it.
      - 14y ago
ams6110 14y ago
Can you name any software that doesn't have an internal API that's not meant for use by 3rd parties?

acqq 14y ago

As far as I see you had a contact with Win API but you haven't understood enough, based on your complaints. Moreover, why do you mention "MySQL" as the team with the access to kernel sources?

huhtenberg 14y ago
You see wrong. And I meant MSSQL, of course. Fixed.
- acqq 14y ago
  Can you than please give a technical reason for you to insist on waiting on more than 64 threads in a single API call, having simply too many threads for good performance anyway when IO Completion Ports could be used instead?
  - ambrop7 14y ago
    He probably doesn't have 64 threads, but he may have much more than 64 files or sockets. After all, the response was to the statement that "WaitForMultipleObjects as a kind of super-select to wait on anything". It clearly isn't, with this arbitrary limitation. The problem with Windows is that there isn't any such super-select, unlike on Linux (see epoll, signalfd, timerfd...). You should take a look at my SO answer which lists six different ways to use sockets in Windows: http://stackoverflow.com/questions/11830839/when-using-iocp-should-i-set-wsaoverlappeds-hevent-to-null-or-to-a-valid-handl/11831450#11831450 http://stackoverflow.com/questions/11830839/when-using-iocp-...
    - acqq 14y ago
      Whatever he has more, waitfor is not the optimal way on Windows for that so it's still a complaint that round holes on Win32 are poor fit for his cubes. First choosing tools then complaining that they don't fit to some goal is typical for beginners.
      - huhtenberg 14y ago
        Do tell me, oh, enlightened one, what I should be using if I have 10K idle network connections and I can't really use IOCP, because I need keep things reasonably portable. That's not even considering that IOCP is a great example of premature optimization at cost of clarity and simplicity. It tries to solve a problem that I don't have and it doesn't offer a simpler solution that would just do. It is not a "hole" for my square peg, it's a freaking snowflake. And expecting a modern OS to have an uncomplicated O(1) API for monitoring sockets is clearly too much to ask.
        ambrop7 14y ago
        It's possible to abstract IOCP and non-blocking sockets into a single interface with reasonable efficiency. For example: - To send data, user calls Socket::send(const char *data, size_t length). This starts sending the given data; the buffer must remain available while data is being sent. IOCP implementation will initiate I/O using WSASend() or similar. - When send operation is complete, the socket implementation calls a Done() callback of the user, and from that point on, the user is allowed to call Socket::send() again. With proper implementation, send() can directly be called from the callback. This interface is very easy to implement on Linux. But on Windows there's a complication, because it's non-trivial to just stop an IOCP I/O operation that is in progress, in case you decide you don't need the socket any more and want to red rid of it NOW. If you just forget about it, there could be a crash when you release your buffer but Windows is still using it. A simple solution is to CancelIo() the socket and do blocking GetQueuedCompletionStatus()s until you get an event inidicating the completion of the pending I/O operation - taking care to queue up any unrelated results you may have gotten, for later processing. However, a more efficient solution is to use reference counting or similar with your buffers, so they only get released when Windows is done with them. I didn't say it's easy, but it's possible.
deleted 14y ago
[deleted]

wfunction 14y ago

> not just MSSQL team that can peek at the source code and cook up a magic combination of function arguments that does not return undocumented Don't leave us hanging... what examples are you referring to?

shubb 14y ago
One problem that the WINE project (windows emulator for unix)has is that windows is full of undocumented APIs, some of which might be really quite useful, which are used by windows internal developers. For WINE, if you are going to write an emulator that runs Microsoft code (like the .net framework, or notepad.exe), you need to find the correct behavior of these undocumented APIs by trial and error. For a developer on Windows, it is perhaps frustrating that MS identifies and solves problems with it's platform, but doesn't publicly release these solutions to you. I work for some random company that makes an SDK, although I mostly make products using it. Many of our best features are hidden - we don't ship the header files with the SDK, but the symbols are there in the binaries. Someone doesn't think they are useful enough to justify the testing expense for a full release. I guess MS have the same thing.
- mikevm 14y ago
  >One problem that the WINE project (windows emulator for unix) Wine Is Not an Emulator.
  - shubb 14y ago
    @Mike - Yes, that is true enough.
  - fnordfnordfnord 14y ago
    What shall we call WINE then? A "pretender"? I'm serious btw. I've never seen a good concise explanation of the way WINE works in comparison to say, an emulator. I have a fairly good idea myself, but I wouldn't want to have to give more than a very brief talk over it.
    - 14y ago

ams6110 14y ago

Can you name any software that doesn't have an internal API that's not meant for use by 3rd parties?