🚀 go-pugleaf

Dmitry V. Irtegov (fat@cnit.nsk.su) wrote:
: >
: >Nope.  Your "twice as many instructions" comment is BS.  You lock,
: >access as many times as you need, then unlock.  You don't have to lock
: >or dereference twice for each access.
:
: Well, reality is much more complex. If you do encapsulated routines
: for access to data structures, like linked lists, etc, you have to do
: lock/unlock in each routine. If you port code from system with linear
: memory, often it is very hard to find block boundaries properly.
: These are examples that spring to mind first.
:

These are good points.  I totally agree that an application using handles
instead of pointers must be designed a certain way.

: >: >
: >: >That says more about your skill as a programmer than it does about the
: >: >Mac's memory scheme.
: >:
: >: Not every programmer wants to go through blockhead exercises that have
: >: nothing to do with the computing task.
: >
: >But they all have to.  It's called programming.  
:
: It is called brainf*cking. On VM systems I do not have to go through
: all that crap, my code is both smaller and faster and memory 
: requirements are comparable or less than Mac or Win3.x.
:

Why do you keep bringing up VM when it does nothing to solve the problem
handles are intended to solve?  As for your comments regarding memory
requirements, I'd like to see some numbers -- code size, peak data size,
etc.

:
: Actually, there are situation when there _is_ need to do indirection per
: each access. And when you try to block your accesses, you might create ugly
: bugs that are very hard to find. On other hand, in VM systems MMU hardware 
: does indirection for you automagicaly.
:

VM has nothing to do with it.  Handles are meant to solve the problem of
internal fragmentation, while paged VM solved external fragmentation.
There are handle-based allocation libraries for UNIX.  MacOS and 16-bit
Windows have VM but still use handles, and for a reason.  You may agree
or disagree with the reason, but VM solves a totally different problem.
--
Jerry J. Shekhel
jerry@cybercom.net