introduce yieldUntil(untilFunction, timeoutMs)
#8317
Conversation
…erruptible under a provided condition useful for ethernet drivers using recurrent scheduled functions
d-a-v
changed the title
yieldUntil(untilFonction, timeoutMs) yieldUntil(untilFunction, timeoutMs)
(the internal API is fixed for the static case)
cores/esp8266/LwipIntfDev.h
Outdated
| @@ -36,7 +36,7 @@ class LwipIntfDev: public LwipIntf, public RawDev | |||
| _mtu(DEFAULT_MTU), | |||
| _intrPin(intr), | |||
| _started(false), | |||
| _default(false) | |||
| _default(true) | |||
There was a problem hiding this comment.
Yes. Changing it to true allows to avoid calling manually eth.setDefault(), which is necessary for valid routing.
There was a problem hiding this comment.
makes sense for one instance, true. ok if not a problem
(but, I wonder if default=false would be safer when there are more)
There was a problem hiding this comment.
If there are more than one interface, only the last "defaulted" one becomes the default route.
I will investigate further on why this is necessary, but last time I checked packets are not routed without it.
I could have delegated the directive to "userland" but I think it is better to let the library deal with defaults so we don't need to change the API or the guidelines / examples when something changes or is fixed.
There was a problem hiding this comment.
so the instance variable does not make sense and it should be a static (and shared between the wifi and the lwipintf class), if every interface wants to become the default on callback?
There was a problem hiding this comment.
Fair enough.
I have moved the default value back to false and updated examples to explicitly use the new interface as default route.
There was a problem hiding this comment.
Should the lwip part also be made aware of default modifications? (with another issue / pr, I gather, not to pollute the changes too too much)
There was a problem hiding this comment.
Modification for "default" is reverted to what it was before the PR no ?
If the question is about "lwip2 - the driver adapter", it is very delicate to update the WiFi interface management code per possible hidden side effect. Maybe a new gh-issue describing the API question might be indeed opened for that purpose.
esp_yield() now also calls esp_schedule(), original esp_yield() function renamed to esp_suspend(). Don't use delay(0) in the Core internals, libraries and examples. Use yield() when the code is supposed to be called from CONT, use esp_yield() when the code can be called from either CONT or SYS. Clean-up esp_yield() and esp_schedule() declarations across the code and use coredecls.h instead. Implement helper functions for libraries that were previously using esp_yield(), esp_schedule() and esp_delay() directly to wait for certain SYS context tasks to complete. Correctly use esp_delay() for timeouts, make sure scheduled functions have a chance to run (e.g. LwIP_Ethernet uses recurrent) Related issues: - #6107 - discussion about the esp_yield() and esp_delay() usage in ClientContext - #6212 - discussion about replacing delay() with a blocking loop - #6680 - pull request introducing LwIP-based Ethernet - #7146 - discussion that originated UART code changes - #7969 - proposal to remove delay(0) from the example code - #8291 - discussion related to the run_scheduled_recurrent_functions() usage in LwIP Ethernet - #8317 - yieldUntil() implementation, similar to the esp_delay() overload with a timeout and a 0 interval
d-a-v
added
invalid
merge-conflict
|
Closing via #7148 |
esp_yield() now also calls esp_schedule(), original esp_yield() function renamed to esp_suspend(). Don't use delay(0) in the Core internals, libraries and examples. Use yield() when the code is supposed to be called from CONT, use esp_yield() when the code can be called from either CONT or SYS. Clean-up esp_yield() and esp_schedule() declarations across the code and use coredecls.h instead. Implement helper functions for libraries that were previously using esp_yield(), esp_schedule() and esp_delay() directly to wait for certain SYS context tasks to complete. Correctly use esp_delay() for timeouts, make sure scheduled functions have a chance to run (e.g. LwIP_Ethernet uses recurrent) Related issues: - esp8266#6107 - discussion about the esp_yield() and esp_delay() usage in ClientContext - esp8266#6212 - discussion about replacing delay() with a blocking loop - esp8266#6680 - pull request introducing LwIP-based Ethernet - esp8266#7146 - discussion that originated UART code changes - esp8266#7969 - proposal to remove delay(0) from the example code - esp8266#8291 - discussion related to the run_scheduled_recurrent_functions() usage in LwIP Ethernet - esp8266#8317 - yieldUntil() implementation, similar to the esp_delay() overload with a timeout and a 0 interval
yieldUntil(untilFunction, timeoutMs)is a delay interruptible under a provided condition.It is useful for ethernet drivers using recurrent scheduled functions.
edit Some WiFi examples are converted to ethernet (mdns, ssl, dhcp/static).
replaces #6212
related: #8120
fixes: #8291