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

Longer delays for Ticker and some internal updates#8625

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

Merged
mcspr merged 14 commits intoesp8266:masterfrommcspr:ticker/longer-delay
Nov 1, 2022

Conversation

@mcspr
Copy link
Collaborator

@mcsprmcspr commentedJul 2, 2022
edited
Loading

resolves#8066

Adds max duration check. In case it is over SDK limit, enable 'repeat'ing timer with a duration proportional to the original one and count until it executes N times, only then run the callback.
Code with durations less than that executes as usual. Original proposal was to not create anything or create some kind of error state... which seems counter-productive to not help out with this pretty solvable use-case.

Three additional updates, while refactoring the class

  • Stronger types for internal time management usingstd::chrono::duration. Works the same,std::chrono::duration handles seconds <-> milliseconds conversion.
  • ::detach() 'once' timer when it finishes. Fixes (unintentional?) side-effect that we remain::active(). Plus, this destroys any lambda-bound variables that will persist with the Ticker object. And, since we can't re-arm with the same function (Ticker::attach_ms(uint32_t just_the_time) and etc.)
  • std::variant aka union for internal callback storage (kind-of similar toTicker with Delegate #6918). Instead of having two separate code paths,always attach our static function and dispatch using type info. Also helps with the issue described above, since it will callstd::function dtor when ptr + arg is attached instead of doing nothing.
  • smarter copy and move, detaching existing timer on assignment and detaching the moved-in timer object in both ctor and assignment. Copying or moving a running timer no longer blindly copies_timer pointer, allowing to disarm the original one. Since we are a simple wrapper aroundos_timer_t, just do the simpler thing (and not re-schedule the callback, try to store original times, etc. polledTimeout already does it and is copyable)

Run everything through a common callback 'variant', don't separate boundstd::function and function pointers. Remeber original argument as partof the ticker.Because SDK does not support durations longer than ~6700seconds,split those into multiple ticks. By default, simply divide by 2until we reach some reasonable duration and use repeating timerinternally.
(both cases save original repeat value)
@mcspr
Copy link
CollaboratorAuthor

Speaking ofvoid(*)(char) tovoid(*)(void*) conversion... Does it actually work correctly for argumentsless than 4 bytes? Don't we have some undefined behaviour here?

@d-a-vd-a-v added this to the3.1 milestoneSep 13, 2022
@d-a-vd-a-v added the alphaincluded in alpha release labelSep 13, 2022
easier to implement than explaining =default failing the compilation.and it also did not make sense to copy at all, ETSTimer is unique andcopy with an active timer will reference will still use the old instance
@mcsprmcspr merged commit27c0591 intoesp8266:masterNov 1, 2022
@mcsprmcspr deleted the ticker/longer-delay branchNovember 1, 2022 17:15
hasenradball pushed a commit to hasenradball/Arduino that referenced this pull requestNov 18, 2024
Adds max duration check. In case it is over SDK limit, enable 'repeat'ing timer with a duration proportional to the original one and count until it executes N times, only then run the callback.Code with durations less than that executes as usual. Original proposal was to not create anything or create some kind of error state... which seems counter-productive to not help out with this pretty solvable use-case.Additional updates, while refactoring the class- Stronger types for internal time management using `std::chrono::duration`. Works the same, `std::chrono::duration` handles seconds <-> milliseconds conversion, and we don't have to remember the time type in each method. (...and even allow `once()` and `attach` as overloads instead of the current `_ms`-suffix, in a future update)- `::detach()` when timer finishes. Fixes (unintentional?) side-effect that we remain `::active()`. Plus, this destroys any lambda-bound variables that will persist with the Ticker object. And, since we can't re-arm with the existing function (`Ticker::attach_ms(uint32_t just_the_time)` and etc.)- `std::variant` aka union for internal callback storage (kind-of similar toesp8266#6918). Instead of having two separate code paths, **always** attach our static function and dispatch using type info. Also helps with the issue described above, since it will call `std::function` dtor when ptr + arg is attached instead of doing nothing.- smarter copy and move, detaching existing timer on assignment and detaching the moved-in timer object in both ctor and assignment. Copying or moving a running timer no longer blindly copies `_timer` pointer, allowing to disarm the original one. Since we are a simple wrapper around `os_timer_t`, just do the simpler thing (and not re-schedule the callback, try to store original times, etc. polledTimeout already does it and is copyable)
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

alphaincluded in alpha release

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Ticker.h - Too-large timeouts should generate an error, not silently fail (was: big float and unt32_t numbers)

2 participants

@mcspr@d-a-v

[8]ページ先頭

©2009-2025 Movatter.jp