qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Stitcher (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Commented: (QPID-2206) thread-local storage prevents build on Mac
Date Wed, 07 Apr 2010 03:01:34 GMT

    [ https://issues.apache.org/jira/browse/QPID-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854309#action_12854309

Andrew Stitcher commented on QPID-2206:

I think there are a number of issues with the TSS part of this patch:

1. Using a new pthread_key_create() for each and every TSS variable is a very bad idea IMO.
There is a limit to the number of keys that can be allocated. 128 is a typical value and there
is no way to ensure the number of uses in our code. Of course we also use external libraries
which may themselves use an unknown number of keys. We are also (in the client case) a library
in someone else's executable it would be unfriendly to use large numbers of keys. The recommended
thing to do is to use a single key per program or library.

2. I think putting all the code in a header file is a bad and unnecessary idea. Particularly
there is a non-inline function defined there which would be in the object files multiple times,
and will require the linker to figure out that it's duplicated.

3. It looks to me that the code has no way to eliminate simultaneous construction of the same
ThreadSpec in multiple threads concurrently, this can happen if you use a function static
__thread which is certainly allowed by the extension and is a useful thing to do (I'm not
sure if our code does this, but it could).

4. I'm not clear that the equivalent to the construction " __thread int a(456)" would be dealt
with correctly.

5. I think the most viable solution to this problem involves modifying the qpid::sys::Thread
class so that it allocates a single key and then deals with allocating space in memory refered
to by this key when necessary. Unfortunately I suspect this is considerably more work than
this approach, and probably involves some C++ nasties like in place construction and destruction.

> thread-local storage prevents build on Mac
> ------------------------------------------
>                 Key: QPID-2206
>                 URL: https://issues.apache.org/jira/browse/QPID-2206
>             Project: Qpid
>          Issue Type: Bug
>          Components: Build Tools
>    Affects Versions: 0.5
>         Environment: Mac OS X 10.5, Xcode 3.2.1
>            Reporter: Aaron Hillegass
>         Attachments: qpidc-0.6-no-tss.patch.bz2
> A lack of thread-local storage prevents a build on the Mac:
>  g++ -DHAVE_CONFIG_H -I. -Igen -I./gen -Werror -pedantic -Wall -Wextra -Wno-shadow -Wpointer-arith
-Wcast-qual -Wcast-align -Wno-long-long -Wvolatile-register-var -Winvalid-pch -Wno-system-headers
-Woverloaded-virtual -g -O2 -MT qpid/sys/posix/AsynchIO.lo -MD -MP -MF qpid/sys/posix/.deps/AsynchIO.Tpo
-c qpid/sys/posix/AsynchIO.cpp  -fno-common -DPIC -o qpid/sys/posix/.libs/AsynchIO.o
> qpid/sys/posix/AsynchIO.cpp:61: error: thread-local storage not supported for this target
> qpid/sys/posix/AsynchIO.cpp:62: error: thread-local storage not supported for this target
> qpid/sys/posix/AsynchIO.cpp:63: error: thread-local storage not supported for this target
> qpid/sys/posix/AsynchIO.cpp:64: error: thread-local storage not supported for this target
> qpid/sys/posix/AsynchIO.cpp:65: error: thread-local storage not supported for this target
> qpid/sys/posix/AsynchIO.cpp:66: error: thread-local storage not supported for this target

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message