3 ms·

I dunno, NT tied IOs to the initiating thread until Vista. This means that you had to keep the initiating thread around or your IOs would be cancelled. NT also

by jstarks 10y ago

I dunno, NT tied IOs to the initiating thread until Vista. This means that you had to keep the initiating thread around or your IOs would be cancelled. NT also has the same flaw mentioned in the article; it ties the IOCP registration to the file object instead of the file handle. This means that you can't use a handle with an IOCP in one process then hand it off to another process. The NT IO model has some nice properties but also some pretty serious warts. I think no one got it right.

wahern 10y ago
kqueue got it right. Not just wrt descriptors but with many other aspects of the API. The BSDs tend to put more thought and abstraction into their designs. Linux and Windows designs tend to be primarily driven by the [expected] most common use case, which often leads to premature design and performance optimizations that over the years prove ill conceived or shortsighted as programming patterns shift. OTOH, Linux and Windows APIs tend to be more immediately useable. On BSD things tend to be more "some assembly required". That's all very general but I have very specific examples in mind, like IOCP vs polling, signalfd vs EVFILT_SIGNAL, inotify v EVFILT_VNODE, containers v jail, and seccomp v pledge[1], others. [1] With seccomp v pledge, seccomp seems like it needs more assembly. But I think the most common expected use case, given that seccomp restrictions are inherited across fork, was that seccomp sandboxes would be created by a core system utility which then invoked other services, sandboxing them without having to modify the services. pledge requires source code modification. pledge, I think, is the better and more useful approach but it necessarily requires some assembly. Same story for containers vs jail, at least until recently.
- _delirium 10y ago
  Regarding pledge: I agree it's a good pragmatic design, but I wouldn't see it as an example of BSD vs. Linux broadly. To my mind it's a very specifically OpenBSD style design, a kind of ruthless reduction to a dozen or so hardcoded cases that cover 90% of the benefit, sane defaults, opposition to configurability if it can at all be avoided, and screw coming up with a clean "general" solution. Other BSDs have gone in different directions. FreeBSD's solution here is capsicum, which predates pledge and is more powerful in principle, but is more difficult to use, so not that many programs in FreeBSD actually use it.
  - wahern 10y ago
    Ah, good point. Capsicum is a much better example of the difference in approaches.

by jstarks 10y ago

wahern 10y ago

kqueue got it right. Not just wrt descriptors but with many other aspects of the API. The BSDs tend to put more thought and abstraction into their designs. Linux and Windows designs tend to be primarily driven by the [expected] most common use case, which often leads to premature design and performance optimizations that over the years prove ill conceived or shortsighted as programming patterns shift. OTOH, Linux and Windows APIs tend to be more immediately useable. On BSD things tend to be more "some assembly required". That's all very general but I have very specific examples in mind, like IOCP vs polling, signalfd vs EVFILT_SIGNAL, inotify v EVFILT_VNODE, containers v jail, and seccomp v pledge[1], others. [1] With seccomp v pledge, seccomp seems like it needs more assembly. But I think the most common expected use case, given that seccomp restrictions are inherited across fork, was that seccomp sandboxes would be created by a core system utility which then invoked other services, sandboxing them without having to modify the services. pledge requires source code modification. pledge, I think, is the better and more useful approach but it necessarily requires some assembly. Same story for containers vs jail, at least until recently.

_delirium 10y ago
Regarding pledge: I agree it's a good pragmatic design, but I wouldn't see it as an example of BSD vs. Linux broadly. To my mind it's a very specifically OpenBSD style design, a kind of ruthless reduction to a dozen or so hardcoded cases that cover 90% of the benefit, sane defaults, opposition to configurability if it can at all be avoided, and screw coming up with a clean "general" solution. Other BSDs have gone in different directions. FreeBSD's solution here is capsicum, which predates pledge and is more powerful in principle, but is more difficult to use, so not that many programs in FreeBSD actually use it.
- wahern 10y ago
  Ah, good point. Capsicum is a much better example of the difference in approaches.