Avoid conflicts with similar declaration of MAX_SOCK_NUM #144
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Great! it was surprise for me now, that yield() also defined as weak function. Thanks!
However, definition of some ethernet library specific handler might allow to avoid re-enterability issues when ethernet functions will be invoked indirectly from yield() handler
in case if some "ethernetYield" will be redefined in sketch , it will be possible to raise some global flags before normal yield() to prevent nested lib invocation.
So, my suggestion to use ethernetYield() weak handler execution in loops inside lib, and to define default weak handler with normal yield(); execution inside
It looks slightly more flexible.