>Dan writes:
>> POSIX.1 does not define a memory locking facility, but POSIX.4 does:
>I'm glad Dan pointed these out...I'd like to be able to use them in
>POSIX (on various machines), except that:
>   1)  the appear to probably be 32-bit address oriented, since "void *address"
>       is usually the default address size; ... which would imply they won't
>       work on 64-bit (or larger) addresses.  (HP-UX has a poor man's
>       64-bit virtual memory, but I'd still like to control it!)
 
Why does "void *" appear to be 32 bit address oriented? It implies *nothing*
about the address size. "void *" is architecture specific, and is the
default pointer size for that architecture. For Intel, Motorola, and most
CPUs it's 32 bits. However, DEC's OSF has it 64 bits (and the newer MIPS as
well?), and Cray's UNICOS has it at 128 bits.
 
size_t is a typedef, also architecture specific. It can be any size as well.
 
And what has 32/64 bit got to do with anything?
 
>   2) Neither HP-UX 10.0 nor IBM AIX 2.3 (admittedly not the latest version!)
>      have mlock/mlockall.
 
What is this implying? That it's POSIX's fault for defining the API? Or is
it HP and IBM's fault for not implementing it? The API appears to be
available now in SVR4 but BSD (and spinoffs) don't appear to have
implemented it yet.
 
>still, I'm looking forward to a real, usable 64-bit and beyond memory
>control API for POSIX/Unix ... maybe in a few years?  There's been some
>noise about HP-UX learning about memory management from MPE/iX ... maybe
>that can spark development of such an API?
 
I'm still looking forward to real usable 64-bit memory on MPE, too. Note
that although you can open a file long-mapped (with a 64-bit pointer), MPE
apparently limits you to a file size of 2 gigabytes. Doesn't sound like 64
bit to me?? Or is there some magic you can pull and get mapped access beyond
2 gigs?
 
POSIX's API allows you to access files or memory of any desired size, easily
beyond 2 gigabytes. See lseek(2), and keep in mind that off_t is
architecture specific just like size_t is. They are typedefs for a *reason*
-- code portability between any architecture. mmap(), munmap(), msync(),
etc. use typedefs as well.
 
POSIX was not so shortsighted as to not be able to see beyond 32 bits.
That's why any API that touches files or memory has undefined (e.g. sky's
the limit) sizes.
 
Can we drop the 64/128/1024/16384/16,777,216 bit discussion? It has nothing
to do with this thread, and sounds suspiciously like chest beating. (And
contributes nothing to this thread except noise).
 
>> Both methods given (the 'debug method' and the 'freeze' method) do not
>> address the need to *programatically* do memory locking from within an
>> application itself. Is there a way or isn't there a way to have an NM
>> program do this on MPE?
>Yes, PM required:
 
Any non-priv modes? If not, any reason why?
 
-Dan
.----------------------------------------------.
|Dan Hollis -- Pharmacy Computer Services, Inc.|
[log in to unmask]      -     (503)476-3139|
`----------------------------------------------'