[sldev] PATCH for SNOW-203 (162)

Philippe (Merov) Bossut merov at lindenlab.com
Tue Sep 15 22:56:10 PDT 2009


Hi Aleric,

On Tue, Sep 15, 2009 at 4:59 AM, Aleric Inglewood <
aleric.inglewood at gmail.com> wrote:

> Can someone review the one-liner of
> https://jira.secondlife.com/browse/SNOW-203 ?
>

I did a quick review (see JIRA). I'm not 100% sure it fixes the issue but
it's worth trying.

Looking into this, I noted there are a number of issues that seem to be all
related to partially fetched textures right now (SNOW-162, SNOW-203,
SNOW-59, SNOW-207, SNOW-48). All of them point to the LLViewerImage code.
The number of flags and members is hard to grok and, as a result, the state
of the object is unclear.

Look at fetch state for instance: there are 4 values (mFetchState,
mHasFetcher, mIsFetching and mFullyLoaded) that must dance in concert to
describe what should be known as a unique fetch state. That can create
issues where the aggregate quadruplet could potentially be describing
something that should not exist. If those states are transitory enough,
we're "safe". If not... Of course, such inconsistencies tend to reveal
themselves as bugs at the wrong moment, when adding or modifying code that
seems to be orthogonal to fetching and which own logic is fine.

I'm tempted to instrument the code to trace the state of the fetcher, decode
priority, boost level and discard level and see if there's a pattern,
forbidden or never used combinations and how we could simplify all that.

That's a chunk of work for sure but with all the work you already did on
this, I wondered if you did something like that. Your thoughts appreciated.

Cheers,
- Merov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090915/a3e14ff5/attachment.htm 


More information about the SLDev mailing list