Bug 1163822 - Current timer implementation has no way to avoid some races
Summary: Current timer implementation has no way to avoid some races
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: core
Version: 3.6.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
URL:
Whiteboard:
Depends On: 1163821
Blocks: glusterfs-3.6.3
TreeView+ depends on / blocked
 
Reported: 2014-11-13 14:33 UTC by Xavi Hernandez
Modified: 2016-08-23 12:30 UTC (History)
2 users (show)

Fixed In Version:
Clone Of: 1163821
Environment:
Last Closed: 2016-08-23 12:30:03 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:

Attachments (Terms of Use)

Description Xavi Hernandez 2014-11-13 14:33:58 UTC 
+++ This bug was initially created as a clone of Bug #1163821 +++

Description of problem:

With the current implementation of timers in gluster, there are some situations that cannot be handled in a safe way. This could lead to race conditions, causing crashes or other unexpected side effects.

Version-Release number of selected component (if applicable): master

Additional info:

A clear example is the release of resources after cancelling a timer (the timer could have not been really cancelled and the callback will run anyway but the caller of gf_timer_call_cancel() has no way to know it).

Additionally, it's not possible to determine if a timer callback has been executed or not, or synchronize with it and know if it has been executed successfully.
Comment 1 Pranith Kumar K 2016-08-23 12:30:03 UTC 
This is fixed as part of 1243187
Note You need to log in before you can comment on or make changes to this bug.