In AvatarFactoryModule.SetApperance(), perform ValidateBakedTextureCache() in the same thread rather than on another one.

The caller is already an async thread from LLClientView so this doesn't hold up the client.
However, launching on a separate thread does remove the effect of m_setAppearanceLock
This was potentially allowing two different SetAppearance threads to interfere with each other, though this probably rarely happens, if at all.
iar_mods
Justin Clark-Casey (justincc) 2011-12-13 20:42:39 +00:00
parent 3a06640730
commit b242ceda1e
2 changed files with 6 additions and 4 deletions

View File

@ -575,8 +575,10 @@ namespace OpenSim.Region.ClientStack.LindenUDP
/// <summary>
/// Add a handler for the given packet type.
/// </summary>
/// <remarks>The packet is handled on its own thread. If packets must be handled in the order in which thye
/// are received then please us ethe synchronous version of this method.</remarks>
/// <remarks>
/// The packet is handled on its own thread. If packets must be handled in the order in which thye
/// are received then please use the synchronous version of this method.
/// </remarks>
/// <param name="packetType"></param>
/// <param name="handler"></param>
/// <returns>true if the handler was added. This is currently always the case.</returns>

View File

@ -150,13 +150,13 @@ namespace OpenSim.Region.CoreModules.Avatar.AvatarFactory
changed = sp.Appearance.SetTextureEntries(textureEntry) || changed;
m_log.InfoFormat("[AVFACTORY]: received texture update for {0}", sp.UUID);
Util.FireAndForget(delegate(object o) { ValidateBakedTextureCache(sp, false); });
ValidateBakedTextureCache(sp, false);
// This appears to be set only in the final stage of the appearance
// update transaction. In theory, we should be able to do an immediate
// appearance send and save here.
}
// save only if there were changes, send no matter what (doesn't hurt to send twice)
if (changed)
QueueAppearanceSave(sp.ControllingClient.AgentId);