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

Nexii Malthus nexiim at googlemail.com
Thu Jun 11 05:12:40 PDT 2009


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.

 - Nexii Malthus

Edit: Re-posting, I wish gmail supported mailing lists automatically.

On Thu, Jun 11, 2009 at 1:10 PM, Nexii Malthus <nexiim at googlemail.com>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.
>
> Nexii Malthus
>
>
> On Thu, Jun 11, 2009 at 12:58 PM, Tigro Spottystripes <
> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090611/92efd772/attachment-0001.htm 


More information about the SLDev mailing list