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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
|
[[!meta copyright="Copyright © 2011 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="libpthread: pthread_key_create, reuse"]]
[[!tag open_issue_libpthread]]
IRC, FreeNode, #hurd, 2011-07-02:
< pinotree> hm, maybe i found a libpthread bug
* pinotree tries a testcase
< pinotree> yesssss, found the bug :)
< pinotree> youpi: it's a problem of the key reuse in pthread_key_create()
< youpi> it doesn't reset it?
< youpi> were you looking at the licq issue?
< pinotree> no, gtest
< youpi> k
< youpi> licq has a failing threadspecific issue
< youpi> [ FAILED ] ThreadSpecificData.dataDeletedWhenThreadExits
< pinotree> basically, pthread_key_delete() does not delete the key values
from the "thread_specifics" ihash
< pinotree> but those were new keys, so i'm not sure it is allowed to
return values of previous keys?
< pinotree> after all, the actual key value is an implementation detail,
applications shouldn't care about it being reused
< pinotree> (imho)
< youpi> Upon key creation, the value NULL shall be associated with the new
key in all active threads.
< youpi> ok, so we have to clear it in all threads
< youpi> that's a pity
< pinotree> or just remove the entry from the hash on key removal
< youpi> pinotree: from all the hashes, you mean?
< pinotree> youpi: from how i see it, adding a snippet like
http://paste.debian.net/121690/ in pthread_key_delete() should do the job
< youpi> that only drops from the current thread
< pinotree> ah hm, other threads
< youpi> we need to drop from all threads
< youpi> that's the pity part
< pinotree> youpi: the licq case could look like a similar issue, at a
veeery quick glance
Test program: [[pthread_key_create_reuse.c]]
2011-11-01:
<pinotree> youpi: about the bug with pthread keys (reuse): would be an
acceptable solution having a mutex for the thread_specifics of each
thread?
<youpi> you mean one per thread, one global, or one per key, or ?
<youpi> what is it supposed to protect?
<pinotree> the thread_specifics of each thread
<youpi> pinotree: but against what?
<pinotree> the idea would be: when destroying a key, iterate over all the
exiting threads and remove the key data from the thread_specifics of each
thread
<youpi> one of the issue is getting to browse through the whole list of
threads
<youpi> the other is concurrency between that, and a thread dying
<pinotree> there's the __pthread_threads_lock rwlock
<youpi> it should be enough to keep it locked during the iteration
<pinotree> but that wouldn't be enough when one thread is destroying a key,
and another one is doing {get,set}specific() on that key
<youpi> that's not supposed to happen
<pinotree> mmm
<youpi> “The effect of calling pthread_getspecific() or
pthread_setspecific() with a key value not obtained from
pthread_key_create() or after key has been deleted with
pthread_key_delete() is undefined.”
<youpi> undefined -> you are allowed to just blow up
<pinotree> but it's not been deleted yet... :)
<youpi> it could be, just a matter of time
<youpi> you're not supposed to rely on time-luckyness :)
<pinotree> mmm
<pinotree> bah, you've convinced me ( :) )
|
