11 ms·
You are confused. File descriptors on linux represent "many different types." They are not just for "disk files". Please see signalfd, timerfd, eventfd, inotify
by dingu 7y ago
You are confused. File descriptors on linux represent "many different types." They are not just for "disk files". Please see signalfd, timerfd, eventfd, inotify, let alone sockets (which themselves represent things other than IP sockets). FD is essentially like handle. epoll therefore works with many different types.
- jdsully 7y agoWhile the Unix philosophy is that everything is a file - that is not the case with Linux. Futexs being a good example. There was an attempt to integrate them but it was done incorrectly with inherent race conditions and abandoned. The VMS and NT philosophies of everything being an object are a bit more general and easier to follow in practice.
- dingu 7y agowhat are you on about? I just gave you the specific examples: timerfd, eventfd, signalfd, inotify... these are all epollable fds in Linux? Futex is a special case because futexes themselves are quite special. There is no userspace equivalent to them in Windows anyway as has been mentioned. Windows Events are similar to what is provided by eventfd, but not as featureful.
- ithkuil 7y agoProbably the core of the issue here is that VMS and derivatives tried to hard to fit everything into a generic handle/fd interface while UNIX historically came with a smaller core with many important API surfaces (like signals or timers) only relatively recently getting absorbed under the unified handle/fd interface, giving the impression it's an afterthought. It's also not something that works on all Unices (e.g. afaik macos has no timerfd). But in all fairness, that problem only exists because OS speciation, as it's biological counterpart, is not as clear cut a concept as one would desire.
- monocasa 7y agoFutexes currently have _no_ kernel state besides in the threads that are currently waiting on them. There's no futex_create system call for instance. It's litreally just a call to "sleep until this memory address changes or a timeout occurs". There's not really anything to make a type around, which is why FUTEX_FD was doomed to failure and they rightly backed it out.
- jdsully 7y agoYou may be surprised to learn that some windows handles are actually just addresses with no kernel state too. A great example is an HMODULE. In fact windows actually reserves a block of user address space that will never be allocated to disambiguate memory vs non memory handles. Its really a pitty these two great systems refuse to learn from each other.
- dingu 7y agoWhat does that have to do with anything? You wouldn't use WFMO to implement a futex in Windows. And regardless of anything in Linux, defending WFMO seems like a strange hill to die on. It's not a great API. I'm calling your bluff too. Which one of the supported waitable handles in Windows are just addresses with no other state? I'm more surprised because they all need an access mask at a minimum, and I thought they all involve an ObCreateObject, even a Mutant... these dusty corners of the kernel are visible through the DDK. Anyway, I would be glad to be shown wrong.
- jdsully 7y agoI’m not sure why theres such animosity in your replies. The goal here is not to defend windows but to point out that handles need not aways refer to kernel objects. It would be possible to provide an orthogonal handle based API even if windows doesn’t always live up to that ideal. Ultimately it seems these systems are just too big to maintain a cohesive design - but it is still an ideal to aspire to.
- monocasa 7y agoThe handle is a _kernel_ address... backed by a validly constructed kernel object. EDIT: And since you dirty edited, can you point to an example of HMODULE or any other dataless HANDLE being used on the syscall interface?
- caf 7y agoWindows has WaitOnAddress() which is similar to a futex, and likewise isn't a HANDLE. "File descriptor" is just a weird spelling of "handle", for historical reasons.