Steve Huston wrote:
Hi David,
sorry.. kind of getting off-topic in the RC-1 thread,
starting a new one.
Good idea.
The problem is that there's a common use case that doesn't work
with
the static libs. If there is a DLL that links with the static
client
libs, and that DLL is dynamically loaded from a running exe, the
process will crash. The underlying problem is
thread-specific storage
declared at compile time that needs the linker's help to
get properly
initialized at run time.
If you don't need to do this (if you are simply building an
executable
linked against the static libs) you'll be ok with just the
client
side. You won't be ok with the broker side, if you end up
needing it.
If you do need the client-side problem resolved, it will require
allocating TSS at run time instead of at compile time as is
done now.
Funny you mention that :) I spent today debugging an issue
only to realize it was exactly what you
say. My static lib was being linked into a dynamically loaded
DLL. My test harness is as simple .exe
that links the lib so I never saw this. I was just about to
(literally) submit a bug report for this
exact problem when I saw this email, so guess it's a known
issue. I couldn't find anything in the
JIRA database but perhaps I was searching on the wrong keywords.
It never made it into JIRA since it was made moot by building
DLLs.
I'm not so sure about that.
Let me clarify... The problems I was having in the app I was working
on went away when qpid was built as DLLs :-)
Were there any patches available for this ? For my purposes I
was to planning add a static
boost::asio::detail::tss_ptr (which uses the Tls* API calls)
to qpid::sys::AsyncIO (windows) and use
it allocate a struct to hold threadReadTotal,
threadReadCount, threadWriteTotal and threadWriteCount
(threadMaxRead and threadMaxReadTimeNs are unused). Thoughts ?
You don't need to do this if building DLLs. If you need static
libs,
you'll have more work to do in the build system since only DLLs
get
built now on Windows.
Hmm, I could be missing something but from what I understand
you'd still have this issue if the
qpidcommon DLL is dynamically loaded (using LoadLibrary), no?
Quite correct. However, this particular usage hasn't come up before.
If an app is doing LoadLibrary on a
DLL it will have no knowledge of the static TLS requirements
of that DLL.
I'm basing this on..
http://support.microsoft.com/kb/118816 and
http://msdn.microsoft.com/en-us/library/2s9wt68x(vs.71).aspx
(note and the very bottom of the page)
It doesn't apply to the cases I was working with, but that's certainly
not exhaustive.
FWIW I made a small change using tss_ptr as mentioned above
and it's working fine now.
Ok, great. Can you please open a JIRA for this and attach patches for
your fix?
apologies for taking so long to get back to you.. I've been swamped and never got around to it (well
I did at one point and my browser died :)
see https://issues.apache.org/jira/browse/QPID-1868 for the issue and my patch (I ended up not using
tss_ptr).
Cheers,
David
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
