Re: svn commit: r713762 - /stdcxx/branches/4.2.x/include/rw/_config.h

View: New views
3 Messages — Rating Filter:   Alert me  

Parent Message unknown Re: svn commit: r713762 - /stdcxx/branches/4.2.x/include/rw/_config.h

by Martin Sebor-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I wonder if it would be worthwhile to give users the ability to
decide whether to enable TLS in case they don't need LoadLibrary()
or not. What do you think?

Martin

faridz@... wrote:

> Author: faridz
> Date: Thu Nov 13 09:57:50 2008
> New Revision: 713762
>
> URL: http://svn.apache.org/viewvc?rev=713762&view=rev
> Log:
> 2008-11-13  Farid Zaripov  <faridz@...>
>
> STDCXX-1023
> * include/rw/_config.h [_WIN32 && _RWSTD_LIB_SRC]: Disable
> using of implicit TLS variables in stdcxx library on Windows.
>
> Modified:
>     stdcxx/branches/4.2.x/include/rw/_config.h
>
> Modified: stdcxx/branches/4.2.x/include/rw/_config.h
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/include/rw/_config.h?rev=713762&r1=713761&r2=713762&view=diff
> ==============================================================================
> --- stdcxx/branches/4.2.x/include/rw/_config.h (original)
> +++ stdcxx/branches/4.2.x/include/rw/_config.h Thu Nov 13 09:57:50 2008
> @@ -278,6 +278,18 @@
>  #ifdef _WIN32
>  #  define _RWSTD_NO_STATIC_MUTEX_INIT
>  #  define _RWSTD_PATH_SEP '\\'
> +#  ifdef _RWSTD_LIB_SRC
> +     // Don't use implicit TLS in our library on Windows because of the TLS
> +     // might not be initialized when our library DLL or the DLL, that
> +     // linked statically against our library, is loaded explicitly using
> +     // LoadLibrary() function. (STDCXX-1023)
> +#    ifndef _RWSTD_NO_TLS
> +#      define _RWSTD_NO_TLS
> +#    endif
> +#    ifdef _RWSTD_THREAD
> +#      undef _RWSTD_THREAD
> +#    endif
> +#  endif   // _RWSTD_LIB_SRC
>  #endif   // _WIN32
>  
>  #ifndef _RWSTD_PATH_SEP
>
>
>


Parent Message unknown Re: svn commit: r713762 - /stdcxx/branches/4.2.x/include/rw/_config.h

by Farid Zaripov-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> I wonder if it would be worthwhile to give users the ability to
> decide whether to enable TLS in case they don't need LoadLibrary()
> or not. What do you think?

  Hmm. I only can say, that nor MSVC run-time, nor STLport nor boost libraries are not
using the implicit TLS.

  Currently the TLS variables are used in 3 places only:
- exception's what-buffer;
- table for random number generator;
- buffer for __rw_tmpbuf().

  We need to check what would be if an exception object is created in one thread (i.e. thus "throw new exception();")
and after catch() the pointer passed to another thread and there deleted?

  The same issue with __rw_tmpbuf(). What would be if we getting the temporary buffer in one thread using
get_temporary_buffer(), and releasing it, using return_temporary_buffer(), in another thread?

Farid.

Re: svn commit: r713762 - /stdcxx/branches/4.2.x/include/rw/_config.h

by Martin Sebor :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Farid Zaripov-2 wrote:
> I wonder if it would be worthwhile to give users the ability to
> decide whether to enable TLS in case they don't need LoadLibrary()
> or not. What do you think?

  Hmm. I only can say, that nor MSVC run-time, nor STLport nor boost libraries are not
using the implicit TLS.

  Currently the TLS variables are used in 3 places only:
- exception's what-buffer;
- table for random number generator;
- buffer for __rw_tmpbuf().
Right. But there might be other opportunities for TLS (e.g., in locale or
maybe in some of the C++ 0x facilities?)

  We need to check what would be if an exception object is created in one thread (i.e. thus "throw new exception();")
and after catch() the pointer passed to another thread and there deleted?
Ouch! Tricky! I hadn't thought of this when I implemented it. I think we
either need to get this case to work or disable TLS for exceptions, but
we can't have it crash (which, I assume, is what happens in this case?)

  The same issue with __rw_tmpbuf(). What would be if we getting the temporary buffer in one thread using
get_temporary_buffer(), and releasing it, using return_temporary_buffer(), in another thread?
That would also be a problem. In this case, though, I think it would
be sufficient to document it as a restriction of the API. IMO, getting
this to work would be more trouble than it's worth.

Martin