Re: [MiNT] LDG vs. SLB vs. custom OVL-thingies

[Paul Wratt <paul.wratt@gmail.com>]

On Wed, Feb 3, 2010 at 4:47 AM, Jo Even Skarstein <joska@online.no> wrote:
> --------------------------------------------------
> From: "Paul Wratt" <paul.wratt@gmail.com>
> Sent: Wednesday, February 03, 2010 9:54 AM
> To: "mint" <mint@lists.fishpool.fi>
> 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