Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2123053004:
No destruction observer in file_path_watcher_linux.cc (Closed)
|
Created:
4 years, 5 months ago by fdoray Modified:
4 years, 3 months ago Reviewers:
Mark Mentovai CC:
chromium-reviews Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionNo destruction observer in file_path_watcher_linux.cc
MessageLoop::current()->Add/RemoveDestructionObserver won't be
supported in base/task_scheduler. This CL removes calls to these
methods from file_path_watcher_linux.cc
Before this CL, FilePathWatcherImpl registered itself to be notified
when the MessageLoop on which the watch was initiated was destroyed.
When that notification was received, it canceled the watch. With this
CL, no cancelation happens when the MessageLoop is destroyed. Instead,
a cancelation happens when the FilePathWatcherImpl is destroyed.
What happens if the MessageLoop is destroyed before the
FilePathWatcherImpl is destroyed?:
If the parent FilePathWatcher is deleted on the MessageLoop thread:
- ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which
synchronously calls
FilePathWatcherImpl::CancelOnMessageLoopThreadOrInDestructor().
That cancels the watch. The FilePathWatcherImpl is destroyed when
the FilePathWatcher releases its reference.
If the parent FilePathWatcher is deleted on another thread:
- ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which posts
a FilePathWatcherImpl::CancelOnMessageLoopThread() task to the
MessageLoop's TaskRunner. Since the MessageLoop has been destroyed,
the task is dropped. This causes the last reference to
FilePathWatcherImpl to be released. ~FilePathWatcherImpl is called
synchronously (and calls
FilePathWatcher::CancelOnMessageLoopThreadOrInDestructor).
Since the MessageLoop doesn't exist anymore, there is no
thread-safety problem.
BUG=616447
Committed: https://crrev.com/7532c960faf5f59ef7031e4488fce36b6e1c1cf0
Cr-Commit-Position: refs/heads/master@{#418349}
Patch Set 1 #Patch Set 2 : self-review #Patch Set 3 : rebase #Messages
Total messages: 16 (11 generated)
Description was changed from ========== No destruction observer in file_path_watcher_linux.cc MessageLoop::current()->Add/RemoveDestructionObserver won't be supported in base/task_scheduler. This CL removes calls to these methods from file_path_watcher_linux.cc Before this CL, FilePathWatcherImpl registered itself to be notified when the MessageLoop on which the watch was initiated was destroyed. When that notification was received, it canceled the watch. With this CL, no cancelation happens when the MessageLoop is destroyed. Instead, a cancelation happens when the FilePathWatcherImpl is destroyed. What happens if the MessageLoop is destroyed before the FilePathWatcherImpl is destroyed? The FilePathWatcherImpl is always deleted after its parent FilePathWatcher. If the parent FilePathWatcher is deleted on the MessageLoop thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which synchronously calls FilePathWatcherImpl::CancelOnMessageLoopThread(). That cancels the watch. The FilePathWatcherImpl is destroyed when the FilePathWatcher releases its reference. If the parent FilePathWatcher is deleted on another thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which posts a FilePathWatcherImpl::CancelOnMessageLoopThread() task to the MessageLoop's TaskRunner. Since the MessageLoop has been destroyed, the task is dropped. This causes the last reference to FilePathWatcherImpl to be released. ~FilePathWatcherImpl is called synchronously (and calls FilePathWatcher::CancelOnMessageLoopThread). Since the MessageLoop doesn't exist anymore, there is no thread-safety problem. BUG=616447 ========== to ========== No destruction observer in file_path_watcher_linux.cc MessageLoop::current()->Add/RemoveDestructionObserver won't be supported in base/task_scheduler. This CL removes calls to these methods from file_path_watcher_linux.cc Before this CL, FilePathWatcherImpl registered itself to be notified when the MessageLoop on which the watch was initiated was destroyed. When that notification was received, it canceled the watch. With this CL, no cancelation happens when the MessageLoop is destroyed. Instead, a cancelation happens when the FilePathWatcherImpl is destroyed. What happens if the MessageLoop is destroyed before the FilePathWatcherImpl is destroyed? The FilePathWatcherImpl is always deleted after its parent FilePathWatcher. If the parent FilePathWatcher is deleted on the MessageLoop thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which synchronously calls FilePathWatcherImpl::CancelOnMessageLoopThreadOrInDestructor(). That cancels the watch. The FilePathWatcherImpl is destroyed when the FilePathWatcher releases its reference. If the parent FilePathWatcher is deleted on another thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which posts a FilePathWatcherImpl::CancelOnMessageLoopThread() task to the MessageLoop's TaskRunner. Since the MessageLoop has been destroyed, the task is dropped. This causes the last reference to FilePathWatcherImpl to be released. ~FilePathWatcherImpl is called synchronously (and calls FilePathWatcher::CancelOnMessageLoopThreadOrInDestructor). Since the MessageLoop doesn't exist anymore, there is no thread-safety problem. BUG=616447 ==========
Description was changed from ========== No destruction observer in file_path_watcher_linux.cc MessageLoop::current()->Add/RemoveDestructionObserver won't be supported in base/task_scheduler. This CL removes calls to these methods from file_path_watcher_linux.cc Before this CL, FilePathWatcherImpl registered itself to be notified when the MessageLoop on which the watch was initiated was destroyed. When that notification was received, it canceled the watch. With this CL, no cancelation happens when the MessageLoop is destroyed. Instead, a cancelation happens when the FilePathWatcherImpl is destroyed. What happens if the MessageLoop is destroyed before the FilePathWatcherImpl is destroyed? The FilePathWatcherImpl is always deleted after its parent FilePathWatcher. If the parent FilePathWatcher is deleted on the MessageLoop thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which synchronously calls FilePathWatcherImpl::CancelOnMessageLoopThreadOrInDestructor(). That cancels the watch. The FilePathWatcherImpl is destroyed when the FilePathWatcher releases its reference. If the parent FilePathWatcher is deleted on another thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which posts a FilePathWatcherImpl::CancelOnMessageLoopThread() task to the MessageLoop's TaskRunner. Since the MessageLoop has been destroyed, the task is dropped. This causes the last reference to FilePathWatcherImpl to be released. ~FilePathWatcherImpl is called synchronously (and calls FilePathWatcher::CancelOnMessageLoopThreadOrInDestructor). Since the MessageLoop doesn't exist anymore, there is no thread-safety problem. BUG=616447 ========== to ========== No destruction observer in file_path_watcher_linux.cc MessageLoop::current()->Add/RemoveDestructionObserver won't be supported in base/task_scheduler. This CL removes calls to these methods from file_path_watcher_linux.cc Before this CL, FilePathWatcherImpl registered itself to be notified when the MessageLoop on which the watch was initiated was destroyed. When that notification was received, it canceled the watch. With this CL, no cancelation happens when the MessageLoop is destroyed. Instead, a cancelation happens when the FilePathWatcherImpl is destroyed. What happens if the MessageLoop is destroyed before the FilePathWatcherImpl is destroyed? The FilePathWatcherImpl is always deleted after its parent FilePathWatcher: If the parent FilePathWatcher is deleted on the MessageLoop thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which synchronously calls FilePathWatcherImpl::CancelOnMessageLoopThreadOrInDestructor(). That cancels the watch. The FilePathWatcherImpl is destroyed when the FilePathWatcher releases its reference. If the parent FilePathWatcher is deleted on another thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which posts a FilePathWatcherImpl::CancelOnMessageLoopThread() task to the MessageLoop's TaskRunner. Since the MessageLoop has been destroyed, the task is dropped. This causes the last reference to FilePathWatcherImpl to be released. ~FilePathWatcherImpl is called synchronously (and calls FilePathWatcher::CancelOnMessageLoopThreadOrInDestructor). Since the MessageLoop doesn't exist anymore, there is no thread-safety problem. BUG=616447 ==========
Description was changed from ========== No destruction observer in file_path_watcher_linux.cc MessageLoop::current()->Add/RemoveDestructionObserver won't be supported in base/task_scheduler. This CL removes calls to these methods from file_path_watcher_linux.cc Before this CL, FilePathWatcherImpl registered itself to be notified when the MessageLoop on which the watch was initiated was destroyed. When that notification was received, it canceled the watch. With this CL, no cancelation happens when the MessageLoop is destroyed. Instead, a cancelation happens when the FilePathWatcherImpl is destroyed. What happens if the MessageLoop is destroyed before the FilePathWatcherImpl is destroyed? The FilePathWatcherImpl is always deleted after its parent FilePathWatcher: If the parent FilePathWatcher is deleted on the MessageLoop thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which synchronously calls FilePathWatcherImpl::CancelOnMessageLoopThreadOrInDestructor(). That cancels the watch. The FilePathWatcherImpl is destroyed when the FilePathWatcher releases its reference. If the parent FilePathWatcher is deleted on another thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which posts a FilePathWatcherImpl::CancelOnMessageLoopThread() task to the MessageLoop's TaskRunner. Since the MessageLoop has been destroyed, the task is dropped. This causes the last reference to FilePathWatcherImpl to be released. ~FilePathWatcherImpl is called synchronously (and calls FilePathWatcher::CancelOnMessageLoopThreadOrInDestructor). Since the MessageLoop doesn't exist anymore, there is no thread-safety problem. BUG=616447 ========== to ========== No destruction observer in file_path_watcher_linux.cc MessageLoop::current()->Add/RemoveDestructionObserver won't be supported in base/task_scheduler. This CL removes calls to these methods from file_path_watcher_linux.cc Before this CL, FilePathWatcherImpl registered itself to be notified when the MessageLoop on which the watch was initiated was destroyed. When that notification was received, it canceled the watch. With this CL, no cancelation happens when the MessageLoop is destroyed. Instead, a cancelation happens when the FilePathWatcherImpl is destroyed. What happens if the MessageLoop is destroyed before the FilePathWatcherImpl is destroyed?: If the parent FilePathWatcher is deleted on the MessageLoop thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which synchronously calls FilePathWatcherImpl::CancelOnMessageLoopThreadOrInDestructor(). That cancels the watch. The FilePathWatcherImpl is destroyed when the FilePathWatcher releases its reference. If the parent FilePathWatcher is deleted on another thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which posts a FilePathWatcherImpl::CancelOnMessageLoopThread() task to the MessageLoop's TaskRunner. Since the MessageLoop has been destroyed, the task is dropped. This causes the last reference to FilePathWatcherImpl to be released. ~FilePathWatcherImpl is called synchronously (and calls FilePathWatcher::CancelOnMessageLoopThreadOrInDestructor). Since the MessageLoop doesn't exist anymore, there is no thread-safety problem. BUG=616447 ==========
The CQ bit was checked by fdoray@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)
fdoray@chromium.org changed reviewers: + mark@chromium.org
PTAL
LGTM
The CQ bit was checked by fdoray@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== No destruction observer in file_path_watcher_linux.cc MessageLoop::current()->Add/RemoveDestructionObserver won't be supported in base/task_scheduler. This CL removes calls to these methods from file_path_watcher_linux.cc Before this CL, FilePathWatcherImpl registered itself to be notified when the MessageLoop on which the watch was initiated was destroyed. When that notification was received, it canceled the watch. With this CL, no cancelation happens when the MessageLoop is destroyed. Instead, a cancelation happens when the FilePathWatcherImpl is destroyed. What happens if the MessageLoop is destroyed before the FilePathWatcherImpl is destroyed?: If the parent FilePathWatcher is deleted on the MessageLoop thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which synchronously calls FilePathWatcherImpl::CancelOnMessageLoopThreadOrInDestructor(). That cancels the watch. The FilePathWatcherImpl is destroyed when the FilePathWatcher releases its reference. If the parent FilePathWatcher is deleted on another thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which posts a FilePathWatcherImpl::CancelOnMessageLoopThread() task to the MessageLoop's TaskRunner. Since the MessageLoop has been destroyed, the task is dropped. This causes the last reference to FilePathWatcherImpl to be released. ~FilePathWatcherImpl is called synchronously (and calls FilePathWatcher::CancelOnMessageLoopThreadOrInDestructor). Since the MessageLoop doesn't exist anymore, there is no thread-safety problem. BUG=616447 ========== to ========== No destruction observer in file_path_watcher_linux.cc MessageLoop::current()->Add/RemoveDestructionObserver won't be supported in base/task_scheduler. This CL removes calls to these methods from file_path_watcher_linux.cc Before this CL, FilePathWatcherImpl registered itself to be notified when the MessageLoop on which the watch was initiated was destroyed. When that notification was received, it canceled the watch. With this CL, no cancelation happens when the MessageLoop is destroyed. Instead, a cancelation happens when the FilePathWatcherImpl is destroyed. What happens if the MessageLoop is destroyed before the FilePathWatcherImpl is destroyed?: If the parent FilePathWatcher is deleted on the MessageLoop thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which synchronously calls FilePathWatcherImpl::CancelOnMessageLoopThreadOrInDestructor(). That cancels the watch. The FilePathWatcherImpl is destroyed when the FilePathWatcher releases its reference. If the parent FilePathWatcher is deleted on another thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which posts a FilePathWatcherImpl::CancelOnMessageLoopThread() task to the MessageLoop's TaskRunner. Since the MessageLoop has been destroyed, the task is dropped. This causes the last reference to FilePathWatcherImpl to be released. ~FilePathWatcherImpl is called synchronously (and calls FilePathWatcher::CancelOnMessageLoopThreadOrInDestructor). Since the MessageLoop doesn't exist anymore, there is no thread-safety problem. BUG=616447 ==========
Message was sent while issue was closed.
Committed patchset #3 (id:40001)
Message was sent while issue was closed.
Description was changed from ========== No destruction observer in file_path_watcher_linux.cc MessageLoop::current()->Add/RemoveDestructionObserver won't be supported in base/task_scheduler. This CL removes calls to these methods from file_path_watcher_linux.cc Before this CL, FilePathWatcherImpl registered itself to be notified when the MessageLoop on which the watch was initiated was destroyed. When that notification was received, it canceled the watch. With this CL, no cancelation happens when the MessageLoop is destroyed. Instead, a cancelation happens when the FilePathWatcherImpl is destroyed. What happens if the MessageLoop is destroyed before the FilePathWatcherImpl is destroyed?: If the parent FilePathWatcher is deleted on the MessageLoop thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which synchronously calls FilePathWatcherImpl::CancelOnMessageLoopThreadOrInDestructor(). That cancels the watch. The FilePathWatcherImpl is destroyed when the FilePathWatcher releases its reference. If the parent FilePathWatcher is deleted on another thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which posts a FilePathWatcherImpl::CancelOnMessageLoopThread() task to the MessageLoop's TaskRunner. Since the MessageLoop has been destroyed, the task is dropped. This causes the last reference to FilePathWatcherImpl to be released. ~FilePathWatcherImpl is called synchronously (and calls FilePathWatcher::CancelOnMessageLoopThreadOrInDestructor). Since the MessageLoop doesn't exist anymore, there is no thread-safety problem. BUG=616447 ========== to ========== No destruction observer in file_path_watcher_linux.cc MessageLoop::current()->Add/RemoveDestructionObserver won't be supported in base/task_scheduler. This CL removes calls to these methods from file_path_watcher_linux.cc Before this CL, FilePathWatcherImpl registered itself to be notified when the MessageLoop on which the watch was initiated was destroyed. When that notification was received, it canceled the watch. With this CL, no cancelation happens when the MessageLoop is destroyed. Instead, a cancelation happens when the FilePathWatcherImpl is destroyed. What happens if the MessageLoop is destroyed before the FilePathWatcherImpl is destroyed?: If the parent FilePathWatcher is deleted on the MessageLoop thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which synchronously calls FilePathWatcherImpl::CancelOnMessageLoopThreadOrInDestructor(). That cancels the watch. The FilePathWatcherImpl is destroyed when the FilePathWatcher releases its reference. If the parent FilePathWatcher is deleted on another thread: - ~FilePathWatcher calls FilePathWatcherImpl::Cancel() which posts a FilePathWatcherImpl::CancelOnMessageLoopThread() task to the MessageLoop's TaskRunner. Since the MessageLoop has been destroyed, the task is dropped. This causes the last reference to FilePathWatcherImpl to be released. ~FilePathWatcherImpl is called synchronously (and calls FilePathWatcher::CancelOnMessageLoopThreadOrInDestructor). Since the MessageLoop doesn't exist anymore, there is no thread-safety problem. BUG=616447 Committed: https://crrev.com/7532c960faf5f59ef7031e4488fce36b6e1c1cf0 Cr-Commit-Position: refs/heads/master@{#418349} ==========
Message was sent while issue was closed.
Patchset 3 (id:??) landed as https://crrev.com/7532c960faf5f59ef7031e4488fce36b6e1c1cf0 Cr-Commit-Position: refs/heads/master@{#418349} |
