| | [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #900
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 1 - Specific to a machine/printer |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | Fl::add_timeout will also consume all the time of embedded low speed CPU |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | wlsloi |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | 1.4.0 |
|---|
| Fix Commit: | da11526bb878e009b93fadd163d18d24e5ca203a |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
No files
Trouble Report Comments:
| |
| #1 | wlsloi
05:40 Jun 02, 2005 |
| The current implement of Fl::add_timeout is almost as same as Fl::repeat_timeout inside a timeout callback. It will consume all the CPU time if the CPU is a embedded low speed or power saving CPU.
It should be better change the FL::add_timeout as follow:
It makes the Fl::add_timeout works more like the time being measured from "now" inside a callback. Therefore, a power saving or low speed CPU would not be fully consumed.
void Fl::add_timeout(double time, Fl_Timeout_Handler cb, void *argp)
{
elapse_timeouts();
Timeout* t = free_timeout;
if (t) free_timeout = t->next;
else t = new Timeout;
t->time = time;
t->cb = cb;
t->arg = argp;
// insert-sort the new timeout:
Timeout** p = &first_timeout;
while (*p && (*p)->time <= time) p = &((*p)->next);
t->next = *p;
*p = t;
} | |
| |
| #2 | matt
13:20 Apr 22, 2008 |
| Is this within scope? | |
| |
| #3 | ianmacarthur
14:22 Apr 22, 2008 |
| I'm not sure it's even true that add_callback will consume all the cpu power - it would have to spend as long in the callback as it waits between callbacks, even with the repeat_callback behaviour... That's either a *very* long callback or a very slow cpu.
Or am I missing something? | |
| |
| #4 | matt
03:17 Jan 20, 2023 |
| I know that Albrecht did a lot of refactoring work to the timers and callback, so I assign this to him, assuming he can simply close the STR and everything was already fixed. | |
| |
| #5 | AlbrechtS
04:51 Jan 20, 2023 |
| Fixed in Git repository.
The given "fix commit" is that of the latest relevant change, when documentation was finally updated.
The new behavior in 1.4.0 on all platforms is that Fl::add_timeout() always measures the timer delay from "now" whereas Fl::repeat_timeout() measures the delay from the time when the current timeout had elapsed.
On slow CPU's it can happen that Fl::repeat_timeout() schedules the next timeout "immediately" (after processing all events and timeouts) if too much time is spent in event handling and other timeouts together, but Fl::add_timeout() doesn't have this effect.
Fl::add_timeout() would still cause consumption of one full core (CPU) for the main FLTK thread if all event handling and timeout processing together used too much CPU time on a very slow CPU, but that can't be changed by the library.
Closing this issue as resolved. | |
[ Return to Bugs & Features ]
|
| |
