3 ms·

The problem here is that most libraries need to integrate into some sort of main loop somehow, and unfortunately there are lots of different ways of doing the m

The problem here is that most libraries need to integrate into some sort of main loop somehow, and unfortunately there are lots of different ways of doing the main loop of the application. Some libraries integrate other things which are not directly poll()-able, but expose the same interface while doing so. Now you have the problem when trying to combine multiple such libraries. For example, you can try using GTK+ and QT in an application at the same time. One thing that has always bugged me is that there is a lack of standardized (cross platform) non-blocking DNS lookup functionality. This adds to the main-loop complexity, since you have to poll() certain types of resources, and have to deal with threads or subprocessed in order to look for DNS results. Well written frameworks like Qt abstract away this complexity, but that may not always play nice when mixing libraries.

ArkyBeagle 10y ago
But the complexity of handling error code returns from UDP/TCP stacks is fundamentally irreducible. IMO, and it's just that - I'd rather deal tactically with fully nonblocking sockets than gamble on the writer of a library's wrapping of it. If it turns out the library works then bonus - but an error code at the socket layer may ripple all the way up to the ... UX layer. The socket handler is the central artifact. If you can, try a socket thing in Tcl. It (SFAIK ) completely asbtracts all the ugly away. Stuff built properly ( see the Brent Welch book for "properly" ) in Tcl will be - again, SFAIK, after ... hundreds of these things ) fully reference grade. And they're very cheap to build. I strongly recommend at least being able to build socket handlers in Tcl because eventually, you'll get into a "he said/she said" over a comms link and using Tcl to test your side is extremely convenient. I had a boss who liked Wireshark and I told him - I don't need Wireshark; I have this test driver. I said this because say you have 2GB of Wireshark spoor. Now what? Just print it out and use a highlighter?

ArkyBeagle 10y ago

But the complexity of handling error code returns from UDP/TCP stacks is fundamentally irreducible. IMO, and it's just that - I'd rather deal tactically with fully nonblocking sockets than gamble on the writer of a library's wrapping of it. If it turns out the library works then bonus - but an error code at the socket layer may ripple all the way up to the ... UX layer. The socket handler is the central artifact. If you can, try a socket thing in Tcl. It (SFAIK ) completely asbtracts all the ugly away. Stuff built properly ( see the Brent Welch book for "properly" ) in Tcl will be - again, SFAIK, after ... hundreds of these things ) fully reference grade. And they're very cheap to build. I strongly recommend at least being able to build socket handlers in Tcl because eventually, you'll get into a "he said/she said" over a comms link and using Tcl to test your side is extremely convenient. I had a boss who liked Wireshark and I told him - I don't need Wireshark; I have this test driver. I said this because say you have 2GB of Wireshark spoor. Now what? Just print it out and use a highlighter?