According to Wikipedia, thread local support is built in to visual studio c/c++, Solaris studio c/c++, IBM c/c++, Gnu gcc, Intel c/c++, and clang.  I haven't done any testing on any platform except osx 10.8 and clang.

I was going to try to do what you suggest, allow the actual  implementation of TLS to be selectable by users, with the default using C# built in support.  I haven't looked yet at what is involved.


On Dec 19, 2013 2:05 AM, "William S Fulton" <> wrote:
Perhaps you can have a macro which a user can use to switch in C++ compiler specific thread local support from the default portable version using C# thread locals?

Which compilers and operating systems did you add in thread local C++ support for?

On 18/12/13 00:10, marvin persona wrote:
I had considered what you suggest - using the thread local support that
C# provides - but it seemed even more complex and even worse
performance.  As an aside, this isn't "C++" thread local (except when
you ARE using C++-11)  It's compiler-specific support for thread locals,
which it seems like all of the "important" compilers support.

But, I'll follow your suggestions and tool out using the C# thread local
built in support.

Thanks for the feedback.


On Dec 17, 2013 6:12 PM, "William S Fulton" <
<>> wrote:

    On 06/12/13 18:00, Marvin Greenberg wrote:


        I've added the director exception support for C# onto my
        "csdirectorexcept" branch at
        As we discussed, this is just a proposal -- the existing
        director_exception_feature test passes, but I suspect there will be
        evolution based on your feedback.

        The main issue (I'm anticipating) is that this implementation
        depends on
        C++ compiler support for thread local.  Performance issues of using
        thread local may warrant a more sophisticated approach, but that
        will be
        even more complex to accomplish in a cross platform way without
        dependency on libraries like boost or pthread.

        This is all similar to the approach you developed to set a
        pending C#
        exception.  In this case, a sample of the C# code generated for the
        director handling code might be:
        catch (MyCSharpException e) {
        // This constructs a pending excetion, stored in thread_local
        "in" wrapper
             return /* $null intermediate type value */ ;

        And just as with your existing "forward mapping" approach, a test is
        made if an exception is pending (in the wrapper code, here) and
        if so
        the already constructed exception is thrown.

        There is another approach that could avoid the need for locking or
        thread local completely. Instead of using a thread local to
        store the
        constructed exception, the return type could be wrapped to allow
        returning the constructed exception when it occurs or 0 otherwise.
        Notionally, for a method returning int:

        internal struct DirectorInt {
            public int value;
            public ulong exception;  // The void* passed back

        catch (MyCSharpException e) {
        // This constructs a pending excetion, stored in thread_local
        "in" wrapper
             ulong e =
             return new DirectorInt($null, e);
        return new DirectorInt(normalValue, 0);  // no error, normal

        There are a lot of details to be worked out about the right
        to get this all compiling, but conceptually it is simple.  The added
        cost is an allocation for every director call (to allocate the extra
        struct), and maybe a copy depending on what the pinvoke
        marshalling does
        (but it seems like that should be avoidable).  It also seems
        like this
        could be done with director (directorin?) typemaps (a new attribute,
        with fragments for the struct declarations?)  But going down
        this path
        will be a fair amount of work.

        One other comment.  When director C# methods throw exceptions, they
        should always be caught. Allowing these exceptions to propagate
        the pinvoke call can cause mono or .Net to fail to call
        destructors on
        allocated objects. Maybe warn if director:except feature is
        cleared, or
        simply document it.

        Remaining work for the existing code:
        Add a multithreaded test for thrown director exceptions.
        Review indentation, etc. of generated code
        Documentation updates

    Yup you guessed right in me thinking that using C++ thread local
    code is not desirable. I wouldn't rule it out completely for the C#
    module as in reality there are not many platforms that support C#.
    Usually this kind of horror is avoided by using the platform
    agnostic facilities inside the target language. So what I suggest is
    you look at doing this stuff in C# and 'simply' make the call into
    C# to do the thread local pending exception setting and testing,
    like it is already done for translating normal C++ exceptions to C#
    exceptions. Neither the design, nor the implementation is
    particularly easy to follow, but once you've 'got it', the concept
    is quite simple and if I may go so far as to say elegant.

    I've always avoided adding the exception info into something
    returned back to C# in the wrappers as it incurs a considerable
    performance overhead for 'chatty' interfaces. Directors are
    definitely slower, so maybe the overhead wouldn't be quite as much,
    but it is quite a radical change and I'd prefer you to try out the
    suggestion in the above paragraph.