Re: looking for elegant C++ abstraction around pthread_key_t...

[Maxim Yegorushkin]

On Oct 30, 11:48 pm, "Chris M. Thomasson" <n...@spam.inva lidwrote:

Here is what I am playing around with now:

[]

Have you looked at http://www.boost.org/doc/libs/1_36_0...l_storage.html
?

--
Max

[Chris M. Thomasson]

Re: looking for elegant C++ abstraction around pthread_key_t.. .


"Maxim Yegorushkin" <maxim.yegorush kin@gmail.comwr ote in message
news:9a891bd5-77e1-4d92-9097-4e40438dade1@i1 8g2000prf.googl egroups.com...
On Oct 30, 11:48 pm, "Chris M. Thomasson" <n...@spam.inva lidwrote:

Here is what I am playing around with now:

[]

Have you looked at
http://www.boost.org/doc/libs/1_36_0...l_storage.html ?

Yeah. I need to look at the actual source-code and see how they deal with
handling the TSD dtor callback. It needs to have C-linkage, and I want to
see how they get it to understand what type its dealing with. Do they use a
base-class, or other trickery that I am not familiar with.

[Maxim Yegorushkin]

Re: looking for elegant C++ abstraction around pthread_key_t.. .

On Oct 31, 6:51 pm, "Chris M. Thomasson" <n...@spam.inva lidwrote:

"Chris M. Thomasson" <n...@spam.inva lidwrote in messagenews:o%H Ok.1694$cx5.507 @newsfe01.iad.. .
>
>
>

"Maxim Yegorushkin" <maxim.yegorush ...@gmail.comwr ote in message
news:9a891bd5-77e1-4d92-9097-4e40438dade1@i1 8g2000prf.googl egroups.com....
On Oct 30, 11:48 pm, "Chris M. Thomasson" <n...@spam.inva lidwrote:

Here is what I am playing around with now:

>

[]

>

Have you looked at
>http://www.boost.org/doc/libs/1_36_0...local_sto....?

>

Yeah. I need to look at the actual source-code and see how they deal with
handling the TSD dtor callback.

The source code which deals with pthread specifics of TLS is here

http://boost.cvs.sourceforge.net/viewvc/boost/boost/libs/thread/src/tss.cpp?revision=HEAD&view=markup

However, boost does not map thread_specific _ptr to pthread_key_t 1:1.
Instead, they boost threads library uses only one pthread_key_t and
implements its own clean up handler mechanism.

It needs to have C-linkage, and I want to
see how they get it to understand what type its dealing with. Do they use
a base-class, or other trickery that I am not familiar with.

Although all POSIX APIs require pointers to functions with C linkage,
on practice all C++ functions and static member functions have C
linkage, it is name mangling what is different. I don't know of any
platform/compiler where this is not true (my knowledge is limited
though).

This is what I did with my own thread specific pointer (intended to be
used for global variables mostly):

http://ccull.svn.sourceforge.net/viewvc/ccull/trunk/include/threads/tls_ptr..h?revision=1&view=markup

--
Max

[Chris M. Thomasson]

Re: looking for elegant C++ abstraction around pthread_key_t.. .


"Maxim Yegorushkin" <maxim.yegorush kin@gmail.comwr ote in message
news:c96cebad-b090-4f34-9751-a37844f067bc@b3 8g2000prf.googl egroups.com...
On Oct 31, 6:51 pm, "Chris M. Thomasson" <n...@spam.inva lidwrote:

"Chris M. Thomasson" <n...@spam.inva lidwrote in
messagenews:o%H Ok.1694$cx5.507 @newsfe01.iad.. .

"Maxim Yegorushkin" <maxim.yegorush ...@gmail.comwr ote in message
>news:9a891bd 5-77e1-4d92-9097-4e40438dade1@i1 8g2000prf.googl egroups.com...
On Oct 30, 11:48 pm, "Chris M. Thomasson" <n...@spam.inva lidwrote:
Here is what I am playing around with now:

>[]

>Have you looked at
>>http://www.boost.org/doc/libs/1_36_0..._local_sto...?

Yeah. I need to look at the actual source-code and see how they deal
with
handling the TSD dtor callback.

The source code which deals with pthread specifics of TLS is here
http://boost.cvs.sourceforge.net/vie...AD&view=markup

However, boost does not map thread_specific _ptr to pthread_key_t 1:1.
Instead, they boost threads library uses only one pthread_key_t and
implements its own clean up handler mechanism.

Ahhh... Okay. Humm, now I wonder why they did it that way. This kind of
seems odd to me. I know that you have to do that on Windows, but under a
POSIX system; why? I suppose it would be good in the sense of you won't run
out of TSD keys. Interesting.

It needs to have C-linkage, and I want to
see how they get it to understand what type its dealing with. Do they
use
a base-class, or other trickery that I am not familiar with.

Although all POSIX APIs require pointers to functions with C linkage,
on practice all C++ functions and static member functions have C
linkage, it is name mangling what is different. I don't know of any
platform/compiler where this is not true (my knowledge is limited
though).

This is what I did with my own thread specific pointer (intended to be
used for global variables mostly):

http://ccull.svn.sourceforge.net/vie...=1&view=markup

Humm... Well, I was going for something that would be as portable as
possible. Murphy's Law comes to mind:


The first use of your TSD will of course be on a platform that does not use
C-linkage for static member functions.


Yikes! ;^)