From eccdd13dd3c812b8f0b3d046ef9d8738df00562a Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 25 Sep 2013 21:45:38 +0200 Subject: IRC. --- ..._spin_lock_locked_ss_critical_section_lock.mdwn | 33 ++++++++++++++-------- 1 file changed, 22 insertions(+), 11 deletions(-) (limited to 'open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn') diff --git a/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn b/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn index cf41550d..7159551d 100644 --- a/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn +++ b/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -16,26 +16,37 @@ License|/fdl]]."]]"""]] IRC, unknown channel, unknown date: - azeem, marcus: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion '! __spin_lock_locked (&ss->critical_section_lock)' failed + azeem, marcus: ext2fs.static: thread-cancel.c:55: + hurd_thread_cancel: Assertion '! __spin_lock_locked + (&ss->critical_section_lock)' failed I actually don't understand this assertion it's just before __spin_lock (&ss->critical_section_lock); why should one check that a lock is free before taking it ? just the same in hurdexec.c - (no, ss is not our own sigstate, so it's not safe to assume no other path can take it) + (no, ss is not our own sigstate, so it's not safe to assume no + other path can take it) there's another one in sysdeps/mach/hurd/spawni.c and jmp-unwind.c - youpi: why do you think it's nonsense?... the fact that we take the lock (so we can't be interrupted) doesn't mean we are willing to wait for others to release the lock... maybe the code path should never be reached while others have a lock, or something + youpi: why do you think it's nonsense?... the fact that we take + the lock (so we can't be interrupted) doesn't mean we are willing to wait + for others to release the lock... maybe the code path should never be + reached while others have a lock, or something then it's useless to take the lock - "we take the lock (so we can't be interrupted)": no, it's not _our_ lock here, it's the lock of the thread we want to cancel - what exactly is cancelling a thread?... (sorry, I don't really have experience with thread programming) + "we take the lock (so we can't be interrupted)": no, it's not _our_ + lock here, it's the lock of the thread we want to cancel + what exactly is cancelling a thread?... (sorry, I don't really + have experience with thread programming) ~= killing it - well, we take the lock so nobody can mess with the thread while we are cancelling it, no?... + well, we take the lock so nobody can mess with the thread while we + are cancelling it, no?... yes that is fine - but checking that the lock is free before taking it doesn't make sense + but checking that the lock is free before taking it doesn't make + sense why nobody should be able to take the lock ? - and if nobody is, why do we take it ? (since nobody would be able to take it) - well, maybe after taking the lock, we do some action that might result in others trying to take it... + and if nobody is, why do we take it ? (since nobody would be able + to take it) + well, maybe after taking the lock, we do some action that might + result in others trying to take it... nope: look at the code :) or maybe the cancel_hook, but I really doubt it - -- cgit v1.2.3