4 ms·

You can do nonblocking IO using the C std library. Poll and select have been in there for decades. They are even in POSIX.

ryandrake 2y ago
poll() and select() are POSIX-isms that are not necessarily going to be present in every system's C standard library. The only reason they happen to be available on Windows is that Microsoft, in an uncharacteristicly freak stroke of respect for existing standards, decided to make WinSock (mostly) function-for-function compatible with BSD sockets.
- jandrese 2y ago
  In practice poll and select exist everywhere it makes sense. There aren't a ton of independent Unix vendors each with their own expensive and broken C implementation running around anymore. Both are available if you use --std=c89 on gcc and clang. At this point it is safe to assume they are available unless you're doing something weird like writing C for some tiny microcontroller. Practically speaking this has been true for at least 20 years.
  - flohofwoe 2y ago
    UNIX isn't the only operating system in the world though, a lot of C programming happens on Windows with MSVC (or embedded platforms, or WASM).
    - jandrese 2y ago
      Yeah, and on those platforms the functions exist if they make sense. If you're talking about some tiny embedded thing with no MMU or OS then it might not, but programming on those is a specialized task anyway so it doesn't really matter.
      - foldr 2y ago
        They're talking about Windows, which doesn't have select/poll (except for sockets, kind of).
  - epcoa 2y ago
    > Both are available if you use --std=c89 on gcc and clang. This is irrelevant - that switch doesn’t have anything to do with controlling functionality not provided by the C standard library. Since poll and select aren’t part of it to begin with it doesn’t affect their availability. epoll and signalfd will be available (on a gcc target where they are available obviously) as well with that switch I don’t think that makes them C standard library functionality. select/poll differs enough across common platforms. In MSVC, poll isn’t there, sure you can emulate but now the goal post moving is getting ridiculous. The arguments to select are only superficially compatible (A practical example is that POSIX select supports pipes, but this will not work on Windows outside of specific environments or 3rd party implementations)
    - shawn_w 2y ago
      Windows has poll(), it's just called WSAPoll() and, like their select(), only works with sockets. https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsapoll https://learn.microsoft.com/en-us/windows/win32/api/winsock2...
      - epcoa 2y ago
        "WSAPoll" because it's not a POSIX poll even though the signature is the same at it works similarly for sockets and I guess Microsoft thought through it better 15 years later. But the original claim is just that select/poll are "everywhere it makes sense", but this depends on what you define select/poll to be. I think something close to POSIX is what makes sense. If you can't use it on pipes and FIFOs (and even regular files without getting an error) that seems like a pretty contrived definition. The whole moving around of definition of what is the C standard library just because of popularity seems unproductive. ("You can do nonblocking IO using the C std library." -- no, you can't) Most popular 3rd party libraries support or can easily support the most popular targets due in large part to them being popular, that means "in practice, they exist everywhere it makes sense." Does this mean all popular 3rd party libraries are part of the C standard library? Colloquially redefining terms like what is the C standard library just sows confusion with no benefit (as was illustrated earlier in regards to threads; C11 threads are not pthreads), just say what you mean in this case.
flohofwoe 2y ago
POSIX isn't the C stdlib though, that's mostly a confusion caused by UNIXes where the libc is the defacto operating system API (and fully implements the POSIX standard). TBF though, I guess one can implement non-blocking IO in C11 with just the stdlib by moving blocking IO calls into threads.
- jandrese 2y ago
  Isn't threading generally handled by POSIX as well? The p in pthreads? If you're writing C code in 2024 and your target is a system that has an OS, then it's safe to use select and poll. They're going to be there. This hand wringing over "oh no, they aren't supported on every platform" is silly because the only platforms where they don't exist are the ones where they don't make sense anyway.
  - flohofwoe 2y ago
    > Isn't threading generally handled by POSIX as well? C11 added threading to the stdlib (https://en.cppreference.com/w/c/thread https://en.cppreference.com/w/c/thread). MSVC is really late to the party (as always): https://devblogs.microsoft.com/cppblog/c11-threads-in-visual-studio-2022-version-17-8-preview-2/ https://devblogs.microsoft.com/cppblog/c11-threads-in-visual... AFAIK select() and poll() are still not supported in MSVC though. IIRC at least select() is provided by 'WinSock' (the Berkeley socket API emulation on Windows), but it only works for socket handles, not for C stdlib file descriptors. In general, if you're used to POSIX, Windows and MSVC is a world of pain. Sometimes a function under the same name exists but works differently, and sometimes a function exists with an underscore, and still works differently. It's usually better to write your own higher level wrapper functions which call into POSIX functions on UNIX-like operating systems, and into Win32 functions on Windows (e.g. ignoring the C stdlib for those feature areas).
    - pjmlp 2y ago
      > MSVC is really late to the party (as always) Mostly because before Satya took over, C on Windows was considered a done deal, and everything was to be done in C++, with C related updated only to the extent required by ISO C++ compliance. https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an... Eventually the change of direction in Microsoft's management, made them backtrack on that decision. Additionally, in what concerns C++ compliance, they are leading up to C++23 in compliance, while everyone else is still missing on full modules, some concepts stuff, parallel STL,... Although something has happened, as the VC++ team has switched away to something else, maybe due to the Rust adoption, .NET finally being AOT proper with lowlevel stuff in C#, or something else. https://old.reddit.com/r/cpp/comments/1ea6gho/microsoft_when_will_c23_compiler_implementation/ https://old.reddit.com/r/cpp/comments/1ea6gho/microsoft_when...

ryandrake 2y ago

poll() and select() are POSIX-isms that are not necessarily going to be present in every system's C standard library. The only reason they happen to be available on Windows is that Microsoft, in an uncharacteristicly freak stroke of respect for existing standards, decided to make WinSock (mostly) function-for-function compatible with BSD sockets.

jandrese 2y ago
In practice poll and select exist everywhere it makes sense. There aren't a ton of independent Unix vendors each with their own expensive and broken C implementation running around anymore. Both are available if you use --std=c89 on gcc and clang. At this point it is safe to assume they are available unless you're doing something weird like writing C for some tiny microcontroller. Practically speaking this has been true for at least 20 years.
- flohofwoe 2y ago
  UNIX isn't the only operating system in the world though, a lot of C programming happens on Windows with MSVC (or embedded platforms, or WASM).
  - jandrese 2y ago
    Yeah, and on those platforms the functions exist if they make sense. If you're talking about some tiny embedded thing with no MMU or OS then it might not, but programming on those is a specialized task anyway so it doesn't really matter.
    - foldr 2y ago
      They're talking about Windows, which doesn't have select/poll (except for sockets, kind of).
- epcoa 2y ago
  > Both are available if you use --std=c89 on gcc and clang. This is irrelevant - that switch doesn’t have anything to do with controlling functionality not provided by the C standard library. Since poll and select aren’t part of it to begin with it doesn’t affect their availability. epoll and signalfd will be available (on a gcc target where they are available obviously) as well with that switch I don’t think that makes them C standard library functionality. select/poll differs enough across common platforms. In MSVC, poll isn’t there, sure you can emulate but now the goal post moving is getting ridiculous. The arguments to select are only superficially compatible (A practical example is that POSIX select supports pipes, but this will not work on Windows outside of specific environments or 3rd party implementations)
  - shawn_w 2y ago
    Windows has poll(), it's just called WSAPoll() and, like their select(), only works with sockets. https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsapoll https://learn.microsoft.com/en-us/windows/win32/api/winsock2...
    - epcoa 2y ago
      "WSAPoll" because it's not a POSIX poll even though the signature is the same at it works similarly for sockets and I guess Microsoft thought through it better 15 years later. But the original claim is just that select/poll are "everywhere it makes sense", but this depends on what you define select/poll to be. I think something close to POSIX is what makes sense. If you can't use it on pipes and FIFOs (and even regular files without getting an error) that seems like a pretty contrived definition. The whole moving around of definition of what is the C standard library just because of popularity seems unproductive. ("You can do nonblocking IO using the C std library." -- no, you can't) Most popular 3rd party libraries support or can easily support the most popular targets due in large part to them being popular, that means "in practice, they exist everywhere it makes sense." Does this mean all popular 3rd party libraries are part of the C standard library? Colloquially redefining terms like what is the C standard library just sows confusion with no benefit (as was illustrated earlier in regards to threads; C11 threads are not pthreads), just say what you mean in this case.

flohofwoe 2y ago

POSIX isn't the C stdlib though, that's mostly a confusion caused by UNIXes where the libc is the defacto operating system API (and fully implements the POSIX standard). TBF though, I guess one can implement non-blocking IO in C11 with just the stdlib by moving blocking IO calls into threads.

jandrese 2y ago
Isn't threading generally handled by POSIX as well? The p in pthreads? If you're writing C code in 2024 and your target is a system that has an OS, then it's safe to use select and poll. They're going to be there. This hand wringing over "oh no, they aren't supported on every platform" is silly because the only platforms where they don't exist are the ones where they don't make sense anyway.
- flohofwoe 2y ago
  > Isn't threading generally handled by POSIX as well? C11 added threading to the stdlib (https://en.cppreference.com/w/c/thread https://en.cppreference.com/w/c/thread). MSVC is really late to the party (as always): https://devblogs.microsoft.com/cppblog/c11-threads-in-visual-studio-2022-version-17-8-preview-2/ https://devblogs.microsoft.com/cppblog/c11-threads-in-visual... AFAIK select() and poll() are still not supported in MSVC though. IIRC at least select() is provided by 'WinSock' (the Berkeley socket API emulation on Windows), but it only works for socket handles, not for C stdlib file descriptors. In general, if you're used to POSIX, Windows and MSVC is a world of pain. Sometimes a function under the same name exists but works differently, and sometimes a function exists with an underscore, and still works differently. It's usually better to write your own higher level wrapper functions which call into POSIX functions on UNIX-like operating systems, and into Win32 functions on Windows (e.g. ignoring the C stdlib for those feature areas).
  - pjmlp 2y ago
    > MSVC is really late to the party (as always) Mostly because before Satya took over, C on Windows was considered a done deal, and everything was to be done in C++, with C related updated only to the extent required by ISO C++ compliance. https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an... Eventually the change of direction in Microsoft's management, made them backtrack on that decision. Additionally, in what concerns C++ compliance, they are leading up to C++23 in compliance, while everyone else is still missing on full modules, some concepts stuff, parallel STL,... Although something has happened, as the VC++ team has switched away to something else, maybe due to the Rust adoption, .NET finally being AOT proper with lowlevel stuff in C#, or something else. https://old.reddit.com/r/cpp/comments/1ea6gho/microsoft_when_will_c23_compiler_implementation/ https://old.reddit.com/r/cpp/comments/1ea6gho/microsoft_when...