On Sat, 12 Jan 2013 02:56:53 +0100, Latif Khalifa wrote: > On Fri, Jan 11, 2013 at 9:13 PM, Henri Beauchamp <sl...@free.fr> wrote: > > Nevermind (though, having a propely built Linux Sunshine-viewer would > > still be a good thing), I figured out the bug (race condition between > > links creation in COF and rebake requests). > > How do you work around that? When I was implementing this in Radegast > it seemed that the service would respond to link creation request and > it would still sometimes fail with COF mismatch as if the baking > service didn't get the message.
Well, my COF implementation is entirely different from LL's... For example, it only uses 3 functions and one callback to sync the COF (and that's because I also implemented *optional* attachments links syncing; without the optional part, i.e. with systematic attachments syncing, it'd take only 2 functions and one callback) and entirely avoids LL's (ridiculously) convoluted code; so it's hard to describe in a message... But to avoid the race conditions, I also modified the requestServerAppearanceUpdate() function and its callback (RequestAgentUpdateAppearanceResponder) so that only one such callback is active at any time (i.e. if other rebake requests are done before the last rebake is completed (or failed), the requests are "queued" (or more exactly, a mNeedsServerSideRebake flag is set and tested for to fire a new rebake on completion of the ongoing one). I also use a timer (gUpdateCOFTimer) that is reset each time a new link is created and tested for before requestServerAppearanceUpdate() is called (the latter being called in one place only, based on the mNeedsServerSideRebake flag and on the timer value). You'd better have a look at my code (at the end of llappearance.cpp) for full understanding of how things work; note that I since found a bug in it: in requestServerAppearanceUpdate(), the test for RequestAgentUpdateAppearanceResponder::isActive() should be moved inside the "if (!responder_ptr.get())" block. The bug only affects rebakes when a request fails and is retried within the RequestAgentUpdateAppearanceResponder callback (which didn't seem to happen so far on Aditi, given the very low load on the server-side rebaker). Note that there seem to be a server-side race condition as well: sometimes, the rebake request succeeds (with matching COF versions) and the viewer does recieve the UUIDs for the baked textures, but when it attempts to fetch the corresponding textures too soon (with 150+ FPS in the testing sims, the delay between the request acknowlegment and the texture fetch that happens at next frame can indeed be very short) the texture fetch fails with a 404 error: if you retrieve it later from a browser using the failed cap, you however do get the corresponding texture, meaning that the rebaker replied "ok" to the request before the texture could be made available by the texture server... Henri. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
