[Libreoffice] Interesting difference in thread-specific data function semantics for Windows vs. Unix

[Caolán McNamara]

On Sun, 2011-06-19 at 14:10 -0600, Tor Lillqvist wrote:
> On Windows, if the value of a key is changed with
>  osl_setThreadKeyData() (or its wrapper, ThreadData::setData()), the
>  destructor callback is called for the old value. (See the code in
>  sal/osl/w32/thread.c. On Unix this does not seem to happen. There
>  osl_setThreadKeyData() is just a thin wrapper for
>  pthread_setspecific(), and the documentation for that does not say
>  anything about the destructor being called. (Experimentation confirms
>  this, at least on Linux.)

Yeah, the documentation for pthread_key_create explicitly says...

"If the  value  associated with a key needs to be updated during the
lifetime of the thread, it may be necessary to release the storage
associated with the old value before the new  value is bound. Although
the pthread_setspecific() function could do this automatically, this
feature is not needed often enough to justify the added complexity.
Instead, the programmer is responsible for freeing the stale storage"

catch is that afaics you can't get the destructor originally set with
pthread_key_create back out from the api anywhere, so you'd need to pass
it around yourself.

>  So, the interesting question now then is whether this difference in 
>  osl_setThreadKeyData() semantics is intentional and known, and handled
>  specifically in those places in the code where thread-specific data is
>  used?

I'd say fat chance that it is intentional and handled correctly
anywhere.

>  Or whether the code assumes the semantics on Windows and just
>  then leaks on Unix? Or what...

Yeah, that'd be my guess.

So we could.

a) forget about it, and have the two platforms different (yuck)
b) make both the same as the pthreads one
c) make both the same as the windows one

If we want c), which is a more attractive and obvious api, then the
attached would do it I think. It does mean a change of the typedef of
oslThreadKey from sal_uInt32 to void*, which changes its size on 64bit.
So technically this is an incompatible change for 64bit binary
extensions that use this obscure api.

Given that the windows api returns a pointer here anyway, I guess this
is required for windows64 anyway, right ? And its sufficiently edge-case
that I doubt there's a single 64bit x86_64 binary linux extension out
there using this api.

C.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.pthreads.like.win.patch
Type: text/x-patch
Size: 4432 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110620/82960e78/attachment.bin>