cosmopolitan/libc/isystem/sys/poll.h

#ifndef COSMOPOLITAN_LIBC_ISYSTEM_SYS_POLL_H_
#define COSMOPOLITAN_LIBC_ISYSTEM_SYS_POLL_H_
#include "libc/calls/weirdtypes.h"
#include "libc/sock/sock.h"
#include "libc/sock/struct/pollfd.h"
#include "libc/sysv/consts/poll.h"
#endif /* COSMOPOLITAN_LIBC_ISYSTEM_SYS_POLL_H_ */
Improve isystem includes and magic numbers 2021-08-15 00:16:33 +00:00			`#ifndef COSMOPOLITAN_LIBC_ISYSTEM_SYS_POLL_H_`
			`#define COSMOPOLITAN_LIBC_ISYSTEM_SYS_POLL_H_`
Fix bugs in poll(), select(), ppoll(), and pselect() poll() and select() now delegate to ppoll() and pselect() for assurances that both polyfill implementations are correct and well-tested. Poll now polyfills XNU and BSD quirks re: the hanndling of POLLNVAL and the other similar status flags. This change resolves a misunderstanding concerning how select(exceptfds) is intended to map to POLPRI. We now use E2BIG for bouncing requests that exceed the 64 handle limit on Windows. With pipes and consoles on Windows our poll impl will now report POLLHUP correctly. Issues with Windows path generation have been fixed. For example, it was problematic on Windows to say: posix_spawn_file_actions_addchdir_np("/") due to the need to un-UNC paths in some additional places. Calling fstat on UNC style volume path handles will now work. posix_spawn now supports simulating the opening of /dev/null and other special paths on Windows. Cosmopolitan no longer defines epoll(). I think wepoll is a nice project for using epoll() on Windows socket handles. However we need generalized file descriptor support to make epoll() for Windows work well enough for inclusion in a C library. It's also not worth having epoll() if we can't get it to work on XNU and BSD OSes which provide different abstractions. Even epoll() on Linux isn't that great of an abstraction since it's full of footguns. Last time I tried to get it to be useful I had little luck. Considering how long it took to get poll() and select() to be consistent across platforms, we really have no business claiming to have epoll too. While it'd be nice to have fully implemented, the only software that use epoll() are event i/o libraries used by things like nodejs. Event i/o is not the best paradigm for handling i/o; threads make so much more sense. 2024-09-02 02:29:47 +00:00			`#include "libc/calls/weirdtypes.h"`
Add more missing libc functionality 2022-08-06 16:56:17 +00:00			`#include "libc/sock/sock.h"`
Fix bugs in poll(), select(), ppoll(), and pselect() poll() and select() now delegate to ppoll() and pselect() for assurances that both polyfill implementations are correct and well-tested. Poll now polyfills XNU and BSD quirks re: the hanndling of POLLNVAL and the other similar status flags. This change resolves a misunderstanding concerning how select(exceptfds) is intended to map to POLPRI. We now use E2BIG for bouncing requests that exceed the 64 handle limit on Windows. With pipes and consoles on Windows our poll impl will now report POLLHUP correctly. Issues with Windows path generation have been fixed. For example, it was problematic on Windows to say: posix_spawn_file_actions_addchdir_np("/") due to the need to un-UNC paths in some additional places. Calling fstat on UNC style volume path handles will now work. posix_spawn now supports simulating the opening of /dev/null and other special paths on Windows. Cosmopolitan no longer defines epoll(). I think wepoll is a nice project for using epoll() on Windows socket handles. However we need generalized file descriptor support to make epoll() for Windows work well enough for inclusion in a C library. It's also not worth having epoll() if we can't get it to work on XNU and BSD OSes which provide different abstractions. Even epoll() on Linux isn't that great of an abstraction since it's full of footguns. Last time I tried to get it to be useful I had little luck. Considering how long it took to get poll() and select() to be consistent across platforms, we really have no business claiming to have epoll too. While it'd be nice to have fully implemented, the only software that use epoll() are event i/o libraries used by things like nodejs. Event i/o is not the best paradigm for handling i/o; threads make so much more sense. 2024-09-02 02:29:47 +00:00			`#include "libc/sock/struct/pollfd.h"`
Add more missing libc functionality 2022-08-06 16:56:17 +00:00			`#include "libc/sysv/consts/poll.h"`
Improve isystem includes and magic numbers 2021-08-15 00:16:33 +00:00			`#endif /* COSMOPOLITAN_LIBC_ISYSTEM_SYS_POLL_H_ */`