8d028e6948
This fixes https://code.google.com/p/singularity-viewer/issues/detail?id=736 The problem was that we need to keep the 'user' derived THREAD_IMPL alive in the thread, and therefore used an LLPointer<THREAD_IMPL> (as base class of AIStateMachineThread<THREAD_IMPL>), and therefore THREAD_IMPL, derived from AIThreadImpl had to be derived from LLThreadSafeRefCount. However, AIStateMachineThread<THREAD_IMPL> also needed to be a statemachine of itself and is derived from AIStateMachineThreadBase derived from AIStateMachine which is ALSO derived from LLThreadSafeRefCount - that in this case wasn't really needed. An attempt to deactive it by calling ref() from the constructor of AIStateMachineThreadBase failed on the fact that LLThreadSafeRefCount insists that its ref count mRef is exactly zero when it is being deleted. The chosen solution is to remove the ref count from AIThreadImpl and use the LLThreadSafeRefCount base class of AIStateMachineThreadBase. The result is that not only THREAD_IMPL, but also the state machine object is kept alive, but that doesn't seem like a problem. Thus, instead of passing a AIThreadImpl* to AIStateMachineThreadBase::Thread, we now pass a AIStateMachineThreadBase* to it to keep the whole of the AIStateMachineThread<THREAD_IMPL> object alive, which has a THREAD_IMPL as member now. This member then can be accessed through a virtual function impl(). Another result of this change is that the 'user' (the class derived from AIThreadImpl, THREAD_IMPL) now has to deal with the LLPointer, and use LLPointer<AIStateMachineThread<THREAD_IMPL> > instead of just AIStateMachineThread<THREAD_IMPL> and also allocate this object himself. The access from there then changes into a -> to access the state machine (as opposed to a .) and ->thread_impl() to access the THREAD_IMPL object (as opposed to a ->).
00000000011111111112222222222333333333344444444445555555555666666666677777777778
12345678901234567890123456789012345678901234567890123456789012345678901234567890
______ ___ __ _ _____ _ _ ______ _____ ___ _____ _ _
|_____ | | \ | | ___ | | | |____| |____/ | | \_/
_____| _|_ | \_| |____| |____| |____ | | | \_ _|_ | |
_ _ _ ____ _ _ ____ ____
\/ | |=== |/\| |=== |--<
Sin-gu-la-ri-ty (noun) - a distinctive feature, a uniqueness; a point at which
continuity breaks up; a point in history at which machine becomes smarter than
humanity and/or fuses with it indivisively; or simply a cool sounding word with
the initials S.G. in it :)
Singularity Viewer is a SecondLife(tm) protocol compatible client application.
It can be used to access SecondLife services as well as a number of others such
as those based upon the OpenSim platform.
Singulariy is maintained by a small group of volunteers who can be contacted
both, in-world (SingularityViewer group) as well on IRC (#SingularityViewer
@ FreeNode). Bug requests and features requests can be submitted through our
Issue Tracker (http://code.google.com/p/singularity-viewer/issues/list or from
the viewer menu: Help --> Bug Reporting --> Singularity Issue Tracker...)
As this Readme grows out of date, please refer to
http://www.singularityviewer.org/about
00000000011111111112222222222333333333344444444445555555555666666666677777777778
12345678901234567890123456789012345678901234567890123456789012345678901234567890
History
The Singularity viewer was started by Siana Gearz in November 2010 by forking it
from the Ascent Viewer, by Balseraph Software Group, which in turn was based upon
source code modified from the snowglobe source code released by Linden Lab.