I don't think that dynamic memory would be hard to implement, but problem is that avatar/parcel have (or is going to have) limited memory available.
1) It is not possible swap memory to server's hard drive - because that would cause lag - and is actually reason behind why memory limits are coming to script world called SL. 2) It is not possible to use your neighbors unused memory - because then your scripts would randomly crash when your neighbors claim their memory back - and it would be bit inconsisted - you can't use your neighbors primitives either! Second problem is that average SL users have limited amount of brain cells and limited amount of patience. They are not going to be happy, if their shop's unique visitor counter "that has been working last few years" suddenly stops working and throws stack overflow exception, because they used sex bed with their girlfriends. They need stability and deterministic behavior. I would be happy to convert dynamic memory supporter, if you could present realistic memory management algorithm that (these are not laws - common sense works here): 1) works in limited memory (doesn't try to use swapping or neighbors unused memory) 2) doesn't need user actions after successful rezzing (user doesn't need to set quotas, prioritize scripts or reset/delete scripts that are using too much memory) 3) script developer can be sure that when object is successfully rezzed it have enough memory for running and basic operations (user for example can't set script's memory limit so small that it can't run) 4) once object is rezzed successfully, scripts in object keeps running until object is derezzed (assuming that script's developer was careful with scripting) 5) algorithm is feasible to implement with current LL hardware - it doesn't need things like large statistic databases to forecast script's memory usage in future 9.3.2010 15:47, Carlo Wood kirjoitti: > It's not impossible... it's actually rather simple. > > That being said, I wouldn't be surprised if LL feels it's too > difficult for them. > > [ I suppose remarks like this (that it is simple) have usually not got > any weight, therefore I already added the fact that I wrote a malloc > library myself in the past that is faster and three times more efficient > than gmalloc (never released though), and already posted a rough outline > of how it could be done. Now I, reluctantly, let me add that the concept > of some individual here knowing something that Linden Lab can't do, is > also not impossible. When I deleted my home directory a few years > ago, then ONLY thing I could find on the net; from the FAQ to the > developers of the filesystem itself, was: you CANNOT undelete files > on an ext3 filesystem. Well, I did; I recovered all 50,000 files > completely; and wrote a (free, open source) program to prove it > (ext3grep) (in case you never heard of that, then I guess you never > deleted file from an ext3 filesystem ;) The HOWTO webpage that I > wrote at the same time, has been translated to Japanese, Russian, > and so on. My English version got 50,000 hits in the first three > days after release). I didn't take "it's impossible" for granted > then, and thousands of people thanked me for that (literally, by > email). I'm not going to take "it's impossible" in this case > either, because this is way way way more simple :/. Sorry, but LL is > just lazy. That is the reason. You're right, let them say that > and I'll crawl back under my rock: "We're just lazy". ] > > On Tue, Mar 09, 2010 at 08:54:45AM +0100, Marine Kelley wrote: > >> supposed to do themselves. Oh of course this is a hard job, allocating >> memory dynamically in an environment like this. Perhaps it is >> impossible. I have yet to hear a Linden say, in all honesty, "sorry >> guys, we can't do it as initially planned, we have to ask you to >> participate by tailoring your scripts, because we can't do it from our >> side". What I have heard so far is "you will be provided tools to >> adapt to the change that is taking place". The two mean exactly the >> same thing, but a little honesty does not hurt. This additional >> workload was not planned, is a shift of work that we were not supposed >> to take in charge in the first place, with no compensation, so I'd >> have liked a little explanation at least. >> > _______________________________________________ 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
