Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix race condition in periodic callback resulting in additional callback executions #5344

Merged

Conversation

Lnk2past
Copy link
Contributor

So I am not convinced I properly ran all of the tests locally, but here is a fix that seems to be working as expected. If there is a clearer path to victory then please let me know. Fixes #5339

Not only did the location of the increment need to change, but checking the counter against the count and signaling a stop also needed to happen before the callback is executed to prevent executions from being scheduled. This now appears to work as expected for any number of threads.

The logic works as follows:

  1. first we check if the periodic is running; this needs to happen to prevent the counter from being incremented after a stop has already been signaled (otherwise, subsequent adds of the periodic do not start at 0). This is important for the case were the count is specified as some number greater than the number of threads allocated.
  2. increment the counter
  3. check if we need to stop
  4. execute the callback if the periodic is still running

A side effect of this is that during execution of the callback, the counter has already been incremented.

@codecov
Copy link

codecov bot commented Jul 28, 2023

Codecov Report

Merging #5344 (79fd585) into main (df0b277) will decrease coverage by 0.03%.
The diff coverage is 80.00%.

@@            Coverage Diff             @@
##             main    #5344      +/-   ##
==========================================
- Coverage   72.70%   72.67%   -0.03%     
==========================================
  Files         274      274              
  Lines       39843    39846       +3     
==========================================
- Hits        28967    28959       -8     
- Misses      10876    10887      +11     
Flag Coverage Δ
unitexamples-tests 72.67% <80.00%> (-0.03%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed Coverage Δ
panel/io/callbacks.py 76.81% <80.00%> (+1.25%) ⬆️

... and 4 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@Lnk2past
Copy link
Contributor Author

Lnk2past commented Jul 28, 2023

I'll add the necessary tests to cover this code some time this weekend.

@philippjfr
Copy link
Member

Thanks for this, I think incrementing before execution is fine.

@philippjfr philippjfr merged commit 3479cc2 into holoviz:main Aug 17, 2023
@Lnk2past
Copy link
Contributor Author

Lnk2past commented Sep 2, 2023

Sorry I dropped the ball on finishing this out! Started a new job and everything is chaos :)

@el-abcd
Copy link

el-abcd commented Sep 9, 2023

I'm wondering if there is an issue with callback timers in version 1.2.2 (if the "count" parameter is left blank).
I have a UI with a counter that ticks up every second, and it seems like it stopped working with panel version 1.2.2 (I reverted to 0.14.3, 1.1.0, and 1.2.1 and see it working well there).
I DID see the counter start working if I set the "count" parameter ...

periodic_cb = pn.state.add_periodic_callback(server_tick_increment, start=True, period=1000, count=1000)
instead of:
periodic_cb = pn.state.add_periodic_callback(server_tick_increment, start=True, period=1000)

This looks like the only change in callbacks.py in release 1.2.2 (IIUC).
I'm not sure, but I'm wondering if perhaps self.count = None if no value is passed in, and some of the comparisons (like "if self.counter > self.count:") might have errors in that case?
If so, perhaps check if self.count = None before that and handle that case differently?

Regards,
Eric

@hoxbro
Copy link
Member

hoxbro commented Sep 9, 2023

@el-abcd, you are completely correct. This is why I have opened a PR #5490, which should fix this regression.

We will make a new release at the start of next week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Race Condition with threaded Periodic Callback can result in additional executions
4 participants