summaryrefslogtreecommitdiff
path: root/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn
blob: f40e0455a364e255770ff0699bd01d424e26e3be (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
[[!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]].