Thanks for the patch, David! I'll review this and integrate for 0.6. The 0.5 release is nearly out the door at this point.
-Steve > -----Original Message----- > From: David Rennalls [mailto:[email protected]] > Sent: Thursday, May 21, 2009 1:29 AM > To: [email protected] > Subject: Re: TLS variables in Windows build (WAS: Re: [0.5] > RC-1 now available) > > > 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] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
