[sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD?

[Melinda Green]

If you think things are complicated now, just wait until we start 
leaning heavily on multithreading to spread the load! There is a special 
circle of hell reserved for debugging threading problems. Seriously 
though, there is work under weigh to use more threads in the viewer to 
tackle some of these sorts of problems. Inventory sorting could well be 
such a task that could be done in parallel and make a noticeable 
difference but I have no idea whether that's true because the inventory 
system is one of the most complex parts of the viewer.

-Melinda

Nexii Malthus wrote:
> Why not simply run inventory sorting in a different thread on the 
> second core? Nearly everyone has at least Dual Core, despite my 
> computer being ancient, I still have at least two cores, one being 
> unused 99% of the time due to the client not being effectively 
> architectured to accomodate multithreading.
>
>     On Thu, Jun 11, 2009 at 12:58 PM, Tigro Spottystripes
>     <tigrospottystripes at gmail.com
>     <mailto:tigrospottystripes at gmail.com>> wrote:
>
>         Melinda Green escreveu:
>         > Tigro Spottystripes wrote:
>         >>
>         >>
>         >>
>         >> The way I would do it would be to make sure the client is
>         completly
>         >> logged in, before trying to make any less important tasks,
>         IMO there
>         >> seems to be too many things being done during login that
>         could just as
>         >> well be done before and/or after login has been
>         stabilished, and have
>         >> the client always prioritize staying connected over other
>         things, never
>         >> the other way around, there is no point in doing anything
>         else if you
>         >> endup disconnected (unless of course if it is after the
>         user has
>         >> requested to be disconnected)
>         >>
>         >> Any insults to the code, if present at all, were only meant
>         to emphasize
>         >> my surprise/disappointment with the existence of apparent
>         flaws and in
>         >> some cases add a bit of comical relief, I never meant to
>         offend anyone.
>         >> I understand that organicly grown software systems tend to
>         get somewhat
>         >> messy, that is often an inherent feature of orgagnicly
>         developed
>         >> anything, take a look a the human body :P
>         >>
>         >> There are great things and ingenious hacks around non-great
>         things, but
>         >> there are a great number of people who would have major
>         changes done
>         >> from scratch instead of built over existing mistakes done,
>         I'm talking
>         >> about the human body, but it also applies to the SL client.
>         >>
>         >> But I am aware that with complex systems, specially
>         organicly developed
>         >> ones, minor changes often produce unexpected results in
>         things that were
>         >> expected to be independent, I do appreciate the work done
>         with SL, it's
>         >> the type of thing that would be expected to not work and
>         yet it does (to
>         >> some extent depending on who you ask), t is amazingly
>         fragile and yet
>         >> unexpectedly robust, in many aspects it's kinda like the
>         Antonov 225,
>         >> too big to fly, reconditioned old tech, and yet it achieves
>         greatly.
>         >>
>         >
>         > Well, now that's the sort of analysis, suggestion, and tone
>         that I
>         > think *is* helpful, thanks!
>         >
>         > Regarding work done on log-in, if we defer doing all those
>         things that
>         > you call  less important (to you, that is), then when the
>         time comes
>         > to do all that work, if they happen all at once, then we're
>         just going
>         > to delay the time before we suddenly grind down and get
>         disconnected.
>         > That's assuming that all those things are atomic and
>         independent,
>         > which they're not. Having spent a fair amount of time in
>         that start-up
>         > code, I know too well what a delicate choreography it
>         requires to make
>         > sure that each service is initialized before it's needed to
>         initialize
>         > some other service. I spent the better part of a month
>         simply turning
>         > about 50 global pointers into proper singletons for exactly that
>         > reason. The reason it took that long was because of circular
>         > interdependencies that needed to be untangled, and this was
>         only one
>         > small part of the start-up process. So I agree that it's
>         almost a
>         > miracle that it works at all.
>         >
>         > Taking your suggestion to it's logical extreme we would end
>         up after
>         > enormous effort with services broken into clean modules that are
>         > packaged as shared libraries that get loaded the first
>         moment they're
>         > accessed, if ever. I like that idea a lot but have to point
>         out that
>         > it's not all upside. Aside from crashes that will happen when an
>         > attempt is made to load a module that didn't get packaged,
>         or when the
>         > wrong version is loaded, users will then experience
>         noticeable pauses
>         > the first time they access major components. Sure, log-in
>         will be
>         > quick, but there will be a new kind of annoyance that
>         happens when you
>         > go to do anything new. So there's value in initializing
>         everything
>         > right up front and in a well-defined order, and there's value in
>         > initializing modules on demand, and none of the choices seem
>         easy or
>         > obvious to me.
>         >
>         > -Melinda
>         >
>
>         is it not possible to prioritize different activities, like always
>         making sure the most important things involved in keeping the
>         client
>         connected always have enough system resources to perform
>         regardless of
>         how much work other things have in mind? I imagine people
>         wouldn't care
>         much about inventory being sorted fast if they get
>         disconnected, things
>         with less priority might run slower, and everything that would
>         cause
>         issues if done without other things having finished first
>         should check
>         if the requirements have been met, and if they haven't, check
>         if they
>         are in the process of getitng done, if not, ask them to start.
>         Doing it
>         like that, nothing should cause disconnections due to
>         timeouts, and
>         regardless of the current state, things would make the right
>         state be
>         achieved. So if the machine is powerful enough, everything
>         gets done
>         before the progress bar reaches the end, and if the machine isn't
>         powerful enough, things will simply load up while they are
>         used, in many
>         cases people are used to things loading gradually, like
>         objects loading
>         from close to far, sculpty and textures progressively getting more
>         details, avatars deruthing property by property (at least that
>         used to
>         be the case before Ruth got hidden away and replaced with the
>         cloud or
>         in some cases simply nothing), I believe people would handle
>         it well if
>         there was active indication of progress, no big stops in
>         progress bars,
>         and no repetitive animation that doesn't differentiate
>         beginning from
>         middle from end of operation, and things like indications of
>         different
>         steps , like text explaining what exactly is being done, or simply
>         icons, colors or changes in the gui that are easily
>         recognizable as
>         individual stages etc are present;. Things shouldn't freeze other
>         things,  gui should remain responsive,  connection essential
>         operations
>         should continue being triggered in time, things being done
>         simultaneously shouldn't hog avaiable resources all to
>         themselves, they
>         should share  the resources, slowing down process depending on
>         their
>         priority, only things with very little priority should ever
>         actually
>         freeze to a halt for any noticeable amount of time, and there
>         should
>         never be doubt for the user about whether things are still
>         working or
>         have reached an irreversible unwelcome state (freeze, crash,
>         or simply
>         hav no idea what to do with the current condition/data and
>         can't find
>         it's way back to normal behavior etc). The user should always
>         be given
>         positive confirmation goals are being achieved, work is being
>         done, that
>         the client knows what it is doing and haven't forgot of the
>         user. If
>         some things already can be done while others are still being
>         prepared,
>         the user should be allowed to do them while not being left in
>         the dark
>         about the progress of what is not avaible yet.
>
>
>         IMO, partial functionality, with information on what is
>         missing and how
>         long till is it avaiable is better than passively watching a
>         progress
>         bar, or having to wonder if the client will ever resume being
>         responssive again.
>         _______________________________________________
>         Policies and (un)subscribe information available here:
>         http://wiki.secondlife.com/wiki/SLDev
>         Please read the policies before posting to keep unmoderated
>         posting privileges
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges