CircuitPython Wiznet5k: PR #178 Socket Reliability Update
PR #178 aligns Wiznet5k sockets with CircuitPython core behavior, improving non-blocking/timeout reliability and consistency.
[Update] Adafruit CircuitPython Wiznet5k Library: PR #178 Improves Core Socket Compatibility & Non-blocking Reliability
The Adafruit_CircuitPython_Wiznet5k library is a key networking driver for Python-based IoT projects built on WIZnet’s hardwired TCP/IP chips.
With Pull Request #178, the library’s socket behavior is aligned more closely with CircuitPython’s core socket semantics—especially around non-blocking mode, timeouts, server accept() loops, and TCP close/disconnect sequences.
Key Improvements
1) accept() behavior matches core socket expectations
For server sockets, accept() now more clearly identifies cases where a connection is not actually established yet, such as:
- returned address is
0.0.0.0or port is0, or - socket status is not
ESTABLISHED
Then it behaves like core socket patterns:
- non-blocking (
timeout == 0) → raisesEAGAIN - blocking with timeout → raises
ETIMEDOUTwhen time expires - blocking (or timeout not expired) → continues waiting
Code excerpt from PR #178:
2) Clear EAGAIN handling in recv_into() for non-blocking reads
In non-blocking mode, if no data is available, recv_into() now raises EAGAIN (consistent with typical socket semantics).
3) More consistent TCP shutdown behavior in close()
For TCP stream sockets, close() now calls _disconnect() first, then releases and closes the socket—improving consistency with core socket behavior.
Why this matters
This merged PR aligns Wiznet5k socket behavior more closely with CircuitPython’s core socket semantics, including consistent handling of states and exceptions such as EAGAIN and ETIMEDOUT. In practice, this can reduce ambiguity when writing non-blocking or timeout-driven loops, making it easier to distinguish “no data yet” from “not connected/accepted yet” and helping application logic behave more predictably.
Notes on “performance”
PR #178 is primarily about behavioral alignment and clearer non-blocking/timeout semantics, rather than a direct SPI throughput optimization. That said, in real applications, cleaner and more consistent state/exception handling can help avoid ambiguous wait conditions and may improve the overall stability and smoothness of long-running network workloads.
❓ FAQ
- Q1. When was PR #178 merged?
A. It was merged into main on Jan 23, 2026.
- Q2. Do I need to update my code?
A. Possibly—especially if your non-blocking logic previously relied on “silent 0-byte reads.” You may need to catch EAGAIN and retry for both accept() and recv_into().
- Q3. Does PR #178 make my projects faster automatically?
A. PR #178 is primarily a behavioral alignment change (matching core socket semantics), not a throughput/SPI optimization patch. Expect more consistent non-blocking/timeout behavior rather than guaranteed speed gains.
Sources
- PR #178 (Match core socket behaviour): https://github.com/adafruit/Adafruit_CircuitPython_Wiznet5k/pull/178
