summaryrefslogtreecommitdiff
path: root/community/gsoc/project_ideas/libdiskfs_locking.mdwn
diff options
context:
space:
mode:
authorantrik <antrik@users.sf.net>2009-03-11 21:37:37 +0100
committerantrik <antrik@users.sf.net>2009-03-12 09:16:47 +0100
commitcd875551b32b895f4049bc94e78067f2cd4783ec (patch)
tree5183055c6110bc9896a3bec6492bde39a2e5c10c /community/gsoc/project_ideas/libdiskfs_locking.mdwn
parentcad09f3e512f8c93f9d355fc1586c3458d2aa205 (diff)
Diskfs locking GSoC task: Add note about code review
Diffstat (limited to 'community/gsoc/project_ideas/libdiskfs_locking.mdwn')
-rw-r--r--community/gsoc/project_ideas/libdiskfs_locking.mdwn4
1 files changed, 4 insertions, 0 deletions
diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn
index c9d55bb7..7212ac8f 100644
--- a/community/gsoc/project_ideas/libdiskfs_locking.mdwn
+++ b/community/gsoc/project_ideas/libdiskfs_locking.mdwn
@@ -23,6 +23,10 @@ runtime. Or implementing a unit testing framework that explicitely checks
locking in various code paths. (The latter could serve as a template for
implementing unit checks in other parts of the Hurd codebase...)
+(A systematic code review would probably suffice to find the existing locking
+issues; but it wouldn't document the work in terms of actual code produced, and
+thus it's not suitable for a GSoC project...)
+
This task requires experience with debugging locking issues in multithreaded
applications.