From mint-bounce@lists.fishpool.fi Wed Feb 3 07:06:41 2010 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=tuorMdPf36gB1+vybzoQmrYMuLesNb6iYW8ataSV7gE=; b=DnaQleWdSWdshbxpFX3KYNOHtHAS4h6oG+vY87pMtAaZULArO73CGe4dhFyOf2cskP vWjWpkR7BhTYHVc9tjBQdThZ8LzFjo2qIh5oIsdN/Dy/a2pcM4660UI/Ie3mxgSOrBTm uDZ+lBmBEKpG7wiGoBT0w40vs+enMDQymbQTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=j/BczlsYQj2DXoWyjnZNnH4QaDO/aLREaVEQtKvldxzc92H662RTK816i9iHF/uQjB 3RTD9SGEFR2RnNFO6qYhPxBBQNHDwPPUU53TeF22bwmVYviZXGvCSV+JT1fumnPAtUKu 7iUxQKVVBYXnlssbXUHbH682e8iUPMp9hJt/s= MIME-Version: 1.0 In-Reply-To: References: <00933E7C-3B49-425B-AFCD-C7BF39DCD2AE@gmail.com> <4B689958.50001@lutece.net> <11a6f2b11002030054j4bd32a42me4037e91497e1f70@mail.gmail.com> Date: Wed, 3 Feb 2010 06:04:18 -0600 Message-ID: <11a6f2b11002030404l31b2877cuf74af412b2328d0@mail.gmail.com> Subject: Re: [MiNT] LDG vs. SLB vs. custom OVL-thingies From: Paul Wratt To: mint Content-Type: text/plain; charset=ISO-8859-1 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: paul.wratt@gmail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: On Wed, Feb 3, 2010 at 4:47 AM, Jo Even Skarstein wrote: > -------------------------------------------------- > From: "Paul Wratt" > Sent: Wednesday, February 03, 2010 9:54 AM > To: "mint" > Subject: Re: [MiNT] LDG vs. SLB vs. custom OVL-thingies > >>> For this job there is alway's a good reason to add to system, this is >>> memory >>> management, simple application have no sure way to lock a memory bloc if >>> a >>> software allocate a memory bloc and crash there is no way to forbid >>> destruction by the system, even Mint SHM not lock memory (I don't >>> remember >>> if Mint share the memory or do a copy, I think it share it). > > Are you sure? I had the impression that a shared memory block exists as long > as atleast one process has an open handle on it. So if two apps (or a shared > lib and an app) shares a memory block and one of them crashes, the memory > block will not be freed. > >>> This is a real big problem to share memory to be able lock we should do a >>> server, if it crash or kill all applications using libs will crash. > > With SLB this is taken care of by the kernel. > >> The server idea means more overhead, something which is a current >> problem for low spec machine. > > That's true, and it's not necessary either. > >> garbage collector also, that they can be updated or changed or even > > What do you mean by "garbage collector"? > >> The documentation for all these just needs to be consolidated and made >> available in at least one (if not 2 or more) central locations, as LDG > > SLB is documented in tos.hyp. Unfortunately there seems to be a lot of > broken links in tos.hyp (well, atleast in the HTML-version at > toshyp.atari.org) ATM. > > Jo Even even with MMU and VMM, there is still a requirement to collect and defragment free memory (also known as garbage collection) The idea of a server is fine, but it can not be the only solution, at the moment anyway, that may change after everyones hardware is dead.. in the meantime you should suggest an suitable solution, created and used in such a way as to allow a server to replace it later, should it be better suited for a particular setup Thanks for the tos.hyp info, yes there are lots of links dead, but it appears all the info is still there, so I will get a a chance to read it at some point no doubt, but it will mean colabrating with Gerhard to get the changes made, and reading the TOShyp at the same time might get a bit laborious.. .. but it has to be done. Paul