From 67e2e8821344db5e4332fa30f6eb711828ae8b9a Mon Sep 17 00:00:00 2001 From: Ingo Weinhold Date: Tue, 29 Apr 2008 21:52:30 +0000 Subject: [PATCH] Added a section to the select() hook documentation discussing the FSs responsibility never to call notify_select_event() after deselect(). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25262 a95241bf-73f2-0310-859d-f6bbb57e9c96 --- docs/user/drivers/fs_interface.dox | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/user/drivers/fs_interface.dox b/docs/user/drivers/fs_interface.dox index 9d1eb0a1b7..eaa3f5ad8b 100644 --- a/docs/user/drivers/fs_interface.dox +++ b/docs/user/drivers/fs_interface.dox @@ -510,6 +510,15 @@ This function is optional. If you don't export it, the default implementation in the VFS will call notify_select_event() directly which will be sufficient for most file systems. + + Note that while select() and the corresponding deselect() are invoked by the + same thread, notifications are usually generated by other threads. It is + your responsibility to make sure that notify_select_event() is never called + for a selectsync object for which deselect() has already returned. This is + commonly done by holding the same lock when invoking notify_select_event() + and when removing the selectsync object from the cookie in deselect(). + Such a lock can be any lock, usually one that is associated with the node or + the volume. */ /*!