Re: [Swig-devel] Director Exception support for C#

[William S F. <ws...@fu...>]

Any kind of thread local variable support will be useful in other target 
languages for inclusion into C or C++ wrappers. If you could put this 
into a separate .swg file for inclusion into the wrappers that would be 
great. Hopefully you end up with some sort of macro that can be used to 
declare a variable thread-local, so that it gets used something like:

SWIG_THREAD_LOCAL(double) myvar; .

William


On 19/12/13 11:26, marvin persona wrote:
> 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.
>
> Marvin
>
> On Dec 19, 2013 2:05 AM, "William S Fulton" <ws...@fu...
> <mailto:ws...@fu...>> 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?
>
>     William
>     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.
>
>         Marvin
>
>         On Dec 17, 2013 6:12 PM, "William S Fulton"
>         <ws...@fu... <mailto:ws...@fu...>
>         <mailto:ws...@fu....__uk
>         <mailto:ws...@fu...>>> wrote:
>
>              On 06/12/13 18:00, Marvin Greenberg wrote:
>
>                  William,
>
>                  I've added the director exception support for C# onto my
>                  "csdirectorexcept" branch at
>         https://github.com/____marvingreenberg/swig
>         <https://github.com/__marvingreenberg/swig>
>                  <https://github.com/__marvingreenberg/swig
>         <https://github.com/marvingreenberg/swig>>.
>                  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
>                  SwigDirector_signal_SWIGTYPE_____MyException(e.Message);
>                       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 =
>
>         SwigDirector_makeCppException_____SWIGTYPE_MyException(e.____Message);
>                       return new DirectorInt($null, e);
>                  }
>                  return new DirectorInt(normalValue, 0);  // no error,
>         normal
>                  return...
>
>                  There are a lot of details to be worked out about the right
>                  incantations
>                  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
>                  through
>                  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
>                  Cleanup.
>
>
>              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.
>
>              William
>
>