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? Thanks, -Steve --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
