Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

introduceyieldUntil(untilFunction, timeoutMs)#8317

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Closed
d-a-v wants to merge12 commits intoesp8266:masterfromd-a-v:ethdelay

Conversation

@d-a-v
Copy link
Collaborator

@d-a-vd-a-v commentedSep 20, 2021
edited
Loading

yieldUntil(untilFunction, timeoutMs) is a delay interruptible under a provided condition.

It is useful for ethernet drivers using recurrent scheduled functions.

edit Some WiFiexamples are converted to ethernet (mdns, ssl, dhcp/static).

replaces#6212
related:#8120
fixes:#8291

…erruptible under a provided conditionuseful for ethernet drivers using recurrent scheduled functions
@d-a-vd-a-v changed the titleintroduceyieldUntil(untilFonction, timeoutMs)introduceyieldUntil(untilFunction, timeoutMs)Sep 20, 2021
_intrPin(intr),
_started(false),
_default(false)
_default(true)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

was this intended?

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Yes. Changing it totrue allows to avoid calling manuallyeth.setDefault(), which is necessary for valid routing.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

makes sense for one instance, true. ok if not a problem
(but, I wonder if default=false would be safer when there are more)

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

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.

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

see alsoWiFi

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

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?

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Fair enough.
I have moved the default value back tofalse and updated examples to explicitly use the new interface as default route.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

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)

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

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.

@d-a-vd-a-v added the alphaincluded in alpha release labelSep 23, 2021
dok-net added a commit to dok-net/arduino-esp8266 that referenced this pull requestOct 6, 2021
dok-net added a commit to dok-net/arduino-esp8266 that referenced this pull requestOct 9, 2021
mcspr pushed a commit that referenced this pull requestOct 16, 2021
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 issupposed 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() andesp_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-vd-a-v added invalid merge-conflictPR has a merge conflict that needs manual correction and removed alphaincluded in alpha release labelsOct 19, 2021
@mcspr
Copy link
Collaborator

Closing via#7148

@mcsprmcspr closed thisOct 19, 2021
dok-net added a commit to dok-net/arduino-esp8266 that referenced this pull requestMar 13, 2022
hasenradball pushed a commit to hasenradball/Arduino that referenced this pull requestNov 18, 2024
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 issupposed 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() andesp_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
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@mcsprmcsprmcspr left review comments

Assignees

No one assigned

Labels

invalidmerge-conflictPR has a merge conflict that needs manual correction

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

WiFiClientSecure not working lwip mode ! (insecure)

2 participants

@d-a-v@mcspr

[8]ページ先頭

©2009-2025 Movatter.jp