Hi Kevin, > From: Kevin Wertman ARA/CFD [mailto:[email protected]] > ... > I ran into the same TLS issue just last week, and made the > following change in ManagementObject.cpp in the 0.5-release > branch to get it working in the short term. > > Index: ManagementObject.cpp > =================================================================== > --- ManagementObject.cpp (revision 777221) > +++ ManagementObject.cpp (working copy) > @@ -172,12 +172,12 @@ > void ManagementObject::setReference(ObjectId) {} > > int ManagementObject::getThreadIndex() { > - static QPID_TSS int thisIndex = -1; > - if (thisIndex == -1) { > + static boost::thread_specific_ptr<int> thisIndex; > + if (thisIndex.get() == NULL) { > sys::Mutex::ScopedLock mutex(accessLock); > - thisIndex = nextThreadIndex; > + thisIndex.reset(new int(nextThreadIndex)); > if (nextThreadIndex < agent->getMaxThreads() - 1) > nextThreadIndex++; > } > - return thisIndex; > + return *thisIndex; > } > > Please let me know if posting this is inappropriate or not in > the correct format and I'll try and make it right. Hope this > is of any help.
This is very helpful, thanks. Could you please include this patch as an attachment to the jira and check the box that allows apache to license it? Other Qpid C++ folks - do you see any issue with using this mechanism on Linux, et al? Please weigh in at https://issues.apache.org/jira/browse/QPID-1868 Thanks, -Steve > -----Original Message----- > From: Steve Huston (JIRA) [mailto:[email protected]] > Sent: Thu 5/21/2009 2:36 PM > To: [email protected] > Subject: [jira] Commented: (QPID-1868) Implicit TLS variables > in AsyncIO can cause access violation when dynamically > loading qpidcommon and qpidclient DLLs > > > [ > https://issues.apache.org/jira/browse/QPID-1868?page=com.atlas sian.jira.plugin.system.issuetabpanels:comment-> tabpanel&focusedCommentId=12711747#action_12711747 ] > > Steve Huston commented on QPID-1868: > ------------------------------------ > > As Andrew noted, we can remove the TSS-based variables in > AsynchIO altogether, which would be easier. They're not > referenced anywhere outside AsynchIO.cpp, so it's no point > jumping through hoops for something that's not used. Sorry I > didn't notice this earlier. > > However, there's another QPID_TSS in > qpid/management/ManagementObject.cpp - since this is included > in qpidcommon, it also needs to be fixed. And, no, requiring > Vista/WinServer 2008 is not an option. Much of the Windows > user world is still in XP land. > > > Implicit TLS variables in AsyncIO can cause access > violation when dynamically loading qpidcommon and qpidclient DLLs > > > -------------------------------------------------------------- > ------------------------------------------------------ > > > > Key: QPID-1868 > > URL: https://issues.apache.org/jira/browse/QPID-1868 > > Project: Qpid > > Issue Type: Bug > > Components: C++ Client > > Affects Versions: 0.5 > > Environment: Windows XP w/SP3 > > Visual Studio 2005 > > Reporter: David Rennalls > > Attachments: AsyncIO_TLS.patch > > > > > > src/qpid/sys/windows/AsynchIO.cpp is using some implicit > thread local storage variables. If the qpid DLLs are > dynamically loaded (or another DLL that statically links in > qpid) no space will be allocated for the TLS data. So if > client code tries to access one of the TLS variables defined > in AsyncIO.cpp it will get an access violation. Taken from [1]... > > "..If a DLL declares any nonlocal data or object as > __declspec( thread ), it can cause a protection fault if > dynamically loaded. After the DLL is loaded with LoadLibrary, > it causes system failure whenever the code references the > nonlocal __declspec( thread ) data. Because the global > variable space for a thread is allocated at run time, the > size of this space is based on a calculation of the > requirements of the application plus the requirements of all > of the DLLs that are statically linked. When you use > LoadLibrary, there is no way to extend this space to allow > for the thread local variables declared with __declspec( > thread ). Use the TLS APIs, such as TlsAlloc, in your DLL to > allocate TLS if the DLL might be loaded with LoadLibrary..." > > ...[2] also warns against this.. > > "Windows Server 2003 and Windows XP: The Visual C++ > compiler supports a syntax that enables you to declare > thread-local variables: _declspec(thread). If you use this > syntax in a DLL, you will not be able to load the DLL > explicitly using LoadLibrary on versions of Windows prior to > Windows Vista. If your DLL will be loaded explicitly, you > must use the thread local storage functions instead of > _declspec(thread)." > > I ran into this when my DLL that links in qpid client and > common libs statically is loaded dynamically by a python > wrapper, the first access to the one of the TLS variables > cause a crash. For reference , [3] (part 1 of 8) has a good > overview of TLS on Windows, and implicit vs explicit TLS > > [1] > http://msdn.microsoft.com/en-us/library/2s9wt68x(vs.71).aspx > - Rules and Limitations for TLS > > [2] http://msdn.microsoft.com/en-us/library/ms684175.aspx - > LoadLibrary function > > [3] http://www.nynaeve.net/?p=180 - Thread Local Storage, > part 1: Overview > > -- > 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:[email protected] > > > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
