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
|
