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

2011-06-20 Thread Caolán McNamara
On Sun, 2011-06-19 at 14:10 -0600, Tor Lillqvist wrote: When run on Linux, I see no such problems. I see a problem about once in 10 or 20 runs under valgrind. I was poking at this last week to see if I could flush the problem out. C. ___ LibreOffice

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

2011-06-20 Thread Caolán McNamara
On Mon, 2011-06-20 at 13:50 +0100, Caolán McNamara wrote: If we want c), which is a more attractive and obvious api, then the attached would do it I think. I decided to push c, hopefully that resolves this correctly. C. ___ LibreOffice mailing list

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

2011-06-20 Thread Michael Meeks
On Mon, 2011-06-20 at 13:50 +0100, Caolán McNamara wrote: 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

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

2011-06-19 Thread Tor Lillqvist
I was investigating why the osl_Thread unit test (sal/qa/osl/process/osl_Thread.cxx) fails most of the times on Windows. If I understand correctly, the problem is a quite fundamental difference in the semantics of thread-specific data keys created with a destructor callback passed to