Non-blocking sockets are the worst
-
Update: https://cse.usf.edu/~kchriste/tools/udpClientNonblock.c[^] Pretty much what I needed. Yay. Update 2: Much ado about nothing. Easier than I thought. Docs are just terrible. Anyone remember the sockets layer from C and C++? Seriously, the fact that someone actually designed them the way that they did, and it made its way through a standards committee just floors me. The blocking stuff is fine, but the non blocking stuff is incomprehensible, at least last time I looked at it. It's absolutely the worst asynchronous API I've ever encountered. I'm about ready to use them in blocking mode on a spawned thread just to avoid it, but the MCU doesn't have a lot of resources and threads are relatively expensive. :(
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Update: https://cse.usf.edu/~kchriste/tools/udpClientNonblock.c[^] Pretty much what I needed. Yay. Update 2: Much ado about nothing. Easier than I thought. Docs are just terrible. Anyone remember the sockets layer from C and C++? Seriously, the fact that someone actually designed them the way that they did, and it made its way through a standards committee just floors me. The blocking stuff is fine, but the non blocking stuff is incomprehensible, at least last time I looked at it. It's absolutely the worst asynchronous API I've ever encountered. I'm about ready to use them in blocking mode on a spawned thread just to avoid it, but the MCU doesn't have a lot of resources and threads are relatively expensive. :(
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I'd be curious to hear more specifically what is wrong about the asynchronous socket API. What is the incomprehensible part. Communication is, in its very nature, asynchronous. So an asynchronous socket API should be the natural way to do it. Synchronous communication is a straitjacket; you can't work or think freely if you have to force yourself into a synchronous framework for communication.
Religious freedom is the freedom to say that two plus two make five.
-
I'd be curious to hear more specifically what is wrong about the asynchronous socket API. What is the incomprehensible part. Communication is, in its very nature, asynchronous. So an asynchronous socket API should be the natural way to do it. Synchronous communication is a straitjacket; you can't work or think freely if you have to force yourself into a synchronous framework for communication.
Religious freedom is the freedom to say that two plus two make five.
IBM Documentation[^] It's anything but natural. Adding, I took a liberty here. I'm using non-blocking and asynchronous interchangeably, but they may not always be in every context.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Update: https://cse.usf.edu/~kchriste/tools/udpClientNonblock.c[^] Pretty much what I needed. Yay. Update 2: Much ado about nothing. Easier than I thought. Docs are just terrible. Anyone remember the sockets layer from C and C++? Seriously, the fact that someone actually designed them the way that they did, and it made its way through a standards committee just floors me. The blocking stuff is fine, but the non blocking stuff is incomprehensible, at least last time I looked at it. It's absolutely the worst asynchronous API I've ever encountered. I'm about ready to use them in blocking mode on a spawned thread just to avoid it, but the MCU doesn't have a lot of resources and threads are relatively expensive. :(
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
And here I am, complaining about non-well-formed CSV files... :doh:
-
And here I am, complaining about non-well-formed CSV files... :doh:
Those are the bane of every programmer.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
-
And here I am, complaining about non-well-formed CSV files... :doh:
My simple rule:
I only read CSVs I wrote.
:-D
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
Update: https://cse.usf.edu/~kchriste/tools/udpClientNonblock.c[^] Pretty much what I needed. Yay. Update 2: Much ado about nothing. Easier than I thought. Docs are just terrible. Anyone remember the sockets layer from C and C++? Seriously, the fact that someone actually designed them the way that they did, and it made its way through a standards committee just floors me. The blocking stuff is fine, but the non blocking stuff is incomprehensible, at least last time I looked at it. It's absolutely the worst asynchronous API I've ever encountered. I'm about ready to use them in blocking mode on a spawned thread just to avoid it, but the MCU doesn't have a lot of resources and threads are relatively expensive. :(
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
use them in blocking mode on a spawned thread
Works for us. We use blocking sockets for both hardware and inter-process communication. It separates threading concerns from communication concerns.
Software Zen:
delete this; -
honey the codewitch wrote:
use them in blocking mode on a spawned thread
Works for us. We use blocking sockets for both hardware and inter-process communication. It separates threading concerns from communication concerns.
Software Zen:
delete this;Separating I/O threads from application threads is an excellent strategy. The I/O threads just do
recvfrom/recvand queue messages as work for the application threads. When no message is waiting for an I/O thread, it's easiest to just let it block (with a timeout if it also has other things to do, like freeing TCP sockets that applications released after the I/O thread last blocked).Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Separating I/O threads from application threads is an excellent strategy. The I/O threads just do
recvfrom/recvand queue messages as work for the application threads. When no message is waiting for an I/O thread, it's easiest to just let it block (with a timeout if it also has other things to do, like freeing TCP sockets that applications released after the I/O thread last blocked).Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.If I wasn't working on a system with a very primitive scheduler and a miserly amount of RAM I would have seriously considered it. It *did* cross my mind. But in the end I got it to work without doing so, and it was actually a bit easier than the documentation seemed to suggest. Helped that I found example code.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
