rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 0 insertions, 54 deletions

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
deleted file mode 100644
index f40e0455..00000000
--- a/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn
+++ /dev/null
@@ -1,54 +0,0 @@
-[[!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
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!meta title="ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion '! __spin_lock_locked (&ss->critical_section_lock)'"]]
-
-[[!tag open_issue_hurd]]
-
-[[!debbug 46859]], [[!debbug 195360]]
-
-IRC, unknown channel, unknown date:
-
-    <youpi> azeem, marcus: ext2fs.static: thread-cancel.c:55:
-      hurd_thread_cancel: Assertion '! __spin_lock_locked
-      (&ss->critical_section_lock)' failed
-    <youpi> I actually don't understand this assertion
-    <youpi> it's just before __spin_lock (&ss->critical_section_lock);
-    <youpi> why should one check that a lock is free before taking it ?
-    <youpi> just the same in hurdexec.c
-    <youpi> (no, ss is not our own sigstate, so it's not safe to assume no
-      other path can take it)
-    <youpi> there's another one in sysdeps/mach/hurd/spawni.c
-    <youpi> and jmp-unwind.c
-    <antrik> 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> then it's useless to take the lock
-    <youpi> "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
-    <antrik> what exactly is cancelling a thread?... (sorry, I don't really
-      have experience with thread programming)
-    <youpi> ~= killing it
-    <antrik> well, we take the lock so nobody can mess with the thread while we
-      are cancelling it, no?...
-    <youpi> yes
-    <youpi> that is fine
-    <youpi> but checking that the lock is free before taking it doesn't make
-      sense
-    <youpi> why nobody should be able to take the lock ?
-    <youpi> and if nobody is, why do we take it ? (since nobody would be able
-      to take it)
-    <antrik> well, maybe after taking the lock, we do some action that might
-      result in others trying to take it...
-    <youpi> nope: look at the code :)
-    <youpi> or maybe the cancel_hook, but I really doubt it
-
-See discussion about *`critical_section_lock`* on [[glibc]].