Re: [ZooLib-dev] Problems using ZooLib with VS 2005

[Andrew G. <ag...@em...>]

On Feb 19, 2005, at 11:22, Paul Nolan wrote:
> I`m back, trying to use the cvs version of zoolib, but have to fix the
> inline functions in the headers causing multply defined symbols again.
> What is the best way for me to fix them, so that the changes can be 
> merged
> back?  It's mainly things like this line in ZAtomic.h.  I`m still 
> learning
> C++, so I`m very tempted to make the functions macros..
>
> inline int ZAtomic_Get(const ZAtomic_t* iAtomic)
> 	{ return iAtomic->fValue; }

This is legal C++. If the compiler is unable to actually inline the 
function it will compile it and put it in the .o of the including 
source file, tagged to indicate that multiple definitions are to be 
expected. In googling for this issue, and what you were finding with 
asm syntax, it seems that you might be using managed C++. In which case 
the code is compiling down to CLI, the asm syntax is different and 
we've got some work to do:)

On Feb 19, 2005, at 12:18, Paul Nolan wrote:
> One more problem I`m afraid, the CVS version of ZThread.cpp has been
> changed to call _getptd(), which from what I can tell was an internal 
> CRT
> function from VC6 that no longer exists, any ideas?
>
> static HANDLE sCurrentThreadHANDLE()
> 	{
> 	if (_tiddata* theData = _getptd())
> 		return theData->_thandle;
> 	return 0;
> 	}

ZSemaphore has stronger semantics than many native semaphore 
implementations. In particular it is safe to dispose a semaphore whilst 
threads are blocked on it. Those threads are woken up and 
ZThread::errorDisposed is returned to them. This was an essential 
feature for some of the UI stuff, although I've generally used other 
mechanisms elsewhere in the code and have given serious thought to 
implementing a parallel set of much lighter synchronization primitives 
that map more closely to what we can expect from the OS.

To support this capability on Win32, we block a thread by recording its 
real thread handle in a waiter structure and calling SuspendThread. 
When it needs to be unblocked we call ResumeThread. GetCurrentThread 
returns a pseudo thread handle, one that means "the current thread" 
rather than a value that has meaning from another thread (the one 
that's calling ResumeThread). In the past we'd look to see if we're 
executing in a ZThread (using TLS) and if so would pull a value from 
fThreadHANDLE. If we created the thread any other way we'd use 
DuplicateHandle to get a real globally-meaningful handle, and then 
dispose it when we were woken up. This is pretty wasteful, as the 
runtime libraries record the thread handle in the structure that lets 
the C library work correctly (set up by beginthread or beginthreadex).

So, the first thing is to determine if you're actually building managed 
C++, in which case we'll need to use quite different techniques, and 
ideally should just leverage the much better .net API. If you're not 
then I'll need to look at the source for the MS runtime. Would you be 
able to zip it up and email it to me?

A+
-- 
Andrew Green                           mailto:ag...@em...
Electric Magic Co.               vox: +1 (831) 621 1822