When a new state machine was just created, so run() had already
been called but it never did really run yet so running() would
return false; then abort() wasn't called in flush(), causing
the subsequent mainloop call to actually try and startup the
state machine, which then crashed because Debug Settings
mechanism is already destroyed at that point (and in general,
we really don't want anything to run: it does unpredictable
things).
With this fix, also state machines that were just created are
aborted, resulting actuall in a kill without delete, and subsequently
a clean delete from the mainloop.
This patch prepares AIStateMachine for the use of AITimer together
with calls to set_state() from other threads. The extra problem
in this case is that the main-thread CAN start running the state
machine again (when the timer times out), while before it was
assumed to be idle until a thread called set_state.
This also takes into account that a thread might call set_state()
and then AGAIN call set_state() before the main thread gets the
chance to call idle() inbetween.
Conflicts:
indra/llmessage/llcurl.cpp
indra/llmessage/llcurl.h
indra/newview/app_settings/settings.xml
indra/newview/llappviewer.cpp
indra/newview/llmeshrepository.cpp
Resolved:
indra/llmessage/llcurl.cpp:
Basically removed (not used anyway)
indra/llmessage/llcurl.h:
Basically removed (just includes aiculr.h now)
indra/newview/app_settings/settings.xml:
CurlUseMultipleThreads was remvoved.
CurlMaximumNumberOfHandles and CurlRequestTimeOut
are still in there, but unused at the moment.
indra/newview/llappviewer.cpp:
CurlMaximumNumberOfHandles and CurlRequestTimeOut
are unused at the moment.
indra/newview/llmeshrepository.cpp:
Lock mSignal always (is unlocked inside wait()).
Use mSignal lock to see if we are waiting; remove mWaiting.
Return false from the MeshFetch functions iff we have to retry
a HTTP fetch. Catch the error exception thrown by getByteRange
instead of using it's return value (always returns true
anyway).
Updated/added documentation.
Removed AIThreadSafeWindowsHack that annoyed me (fix your compiler).
Don't use 'static' in anonymous namespace.
Use the AIThreadSafe*DC variants for default constructed objects,
as opposed to the AITHREADSAFE* macro's.
This was already documented as working, but turned out not to work.
Now one can call any of the run(...) functions to guarantee a restart
of the statemachine. Using run() without parameters from a callback
function re-uses the old callback information.
Introduces a new enum AIStateMachine::active_type that keeps track
of on which list the statemachine resides, if any. This was necessary
because run() calls cont() which now can be called while the
statemachine is already on the active list, so it needs to know
more than just if it's on the continued_statemachines list or
not.
Added a new statemachine AIFetchInventoryFolder, which can be used
to fetch the contents of a folder by name or UUID.
Also added AIEvent (and one event,
AIEvent::LLInventoryModel_mIsAgentInvUsable_true, which is needed
for AIFetchInventoryFolder).
Fixed LLInventoryModel::sBackgroundFetchActive to correctly reflect
whether or not LLInventoryModel::backgroundFetch is added to
gIdleCallbacks.
Avoid duplicated entries in sFetchQueue.
Reset sFullFetchStarted in LLInventoryModel::stopBackgroundFetch to
allow for a renewed full fetch when some single-folder fetch stops it.
Added AIStateMachine::mQueued to make calling 'cont()' more robust:
calling cont() / idle() / cont() on a row would otherwise add a
statemachine twice to the active list, which would cause a crash
when it's killed.
Call AIFilePicker::create() instead of new AIFilePicker.
Renamed deleteMe() to kill() and bs_deleted to bs_killed.
Only default to auto destruct when created with create(true),
otherwise kill() has to be called explicitely.
This is the skeleton needed to implement classes that can be reused and
work together, which can perform asynchronous tasks (read: need to wait
for certain events before they can continue).
An example would be the task of waiting for a given inventory folder to
be read. This could then be used to improve the builtin AO
(automatically reading that folder when a notecard is dropped, and
continuing when the whole folder is read).
It's first use will be communication with a filepicker that runs
in a plugin.