LabVIEW

TCP - Allow files descriptors > 1024

@rolfk wrote:

Well, if it would be that simple it's of course a big question why it hasn't already been done loooong ago! 🙂

That's actually a pretty good question, although you probably didn't mean it to be that good. 😀

Small clarification: I wouldn't call any of this "simple". Merely overestimated.

On the Linux side there has been a pretty large amount of API churn: first poll(), then epoll(), then io_uring. (And that's leaving out the insanity that's gone on in the userspace driver space like DPDK.) (The Windows side hasn't evolved nearly as much AFAIK, although we couldn't have relied on IOCPs until well after all of this was written, and RIO is an interesting interloper.)

Given evolutions in an underlying technology stack, we can't necessarily justify upgrading APIs simply because they are newer, when the older APIs work fine, because, hey, as soon as you're done upgrading, the next new thing will come up in a few years and make the new code obsolete. At the end of the day, I think that the only Linux async network API that upstream is actually "happy" about — i.e. intuitively the right approach, no intrinsic flaws, clear paths to optimal performance, upstream developer interest — is io_uring, and that's only been considered production-ready for the past few years.

At the same time, slam-dunk performance or functionality arguments are hard to come by. (In particular, any time that an application gets bottlenecked by LabVIEW's TCP/IP performance, you would probably be recommended to write a DLL anyway and do all of your network I/O yourself. And for a couple of products, you don't even want to be using the OS-provided TCP/IP stack in the first place.) That's blunted a lot of the slam-dunk-showstopper arguments for feature development that would otherwise have raised the priority of this sort of thing.