Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upmulti: mandate use "expire ID" for timers #1472
Conversation
This comment has been minimized.
This comment has been minimized.
mention-bot
commented
May 8, 2017
@bagder, thanks for your PR! By analyzing the history of the files in this pull request, we identified @tatsuhiro-t, @yangtse and @dfandrich to be potential reviewers. |
bagder
force-pushed the
bagder/timer-id
branch
from
38e9f17
to
8469fef
May 8, 2017
bagder
force-pushed the
bagder/timer-id
branch
from
8469fef
to
c707642
May 8, 2017
bagder
closed this
in
31b39c4
May 10, 2017
bagder
deleted the
bagder/timer-id
branch
May 11, 2017
This comment has been minimized.
This comment has been minimized.
paulharris
commented
Jun 8, 2017
Hello there, I have a question about this change. I have only dug into the code a little, so this could be a silly question. The timers all now have IDs, so you now have a fixed set of timer "categories". If we need to test for something (eg speedtest), the code calls In code... something like... hmm... make up a scenario....
I suggest that Curl_expire_latest become simply Curl_expire(id), and always adjust the timer. Without digging into the code any more, I would guess that this will not affect performance, because (in my scenario) task1 and task2 are going to be called no matter what timer goes off (my assumption at the top). Thoughts? |
This comment has been minimized.
This comment has been minimized.
Thanks a lot for your valuable thoughts and feedback. Yes I can totally see how you're right and that this change sort of "broke" Curl_expire_latest() for exactly the reasons you state. I intend to proceed as you suggest and replace Curl_expire_latest() with plain Curl_expire()... Thanks again. I'll follow up with a separate PR. |
This comment has been minimized.
This comment has been minimized.
Curl_expire_latest() removal in PR #1555 |
This comment has been minimized.
This comment has been minimized.
paulharris
commented
Jun 8, 2017
Thanks |
bagder commentedMay 8, 2017
[internals only, no user-visible change]
This allows us to remove running timers without having them expire "in vain". It makes the typical list of "running timers" much shorter (now usually just 0-2 entries, from previously when it could easily grow to 6-10). It then also allows us to use a fixed array of possible timers so we can do them without using malloc.