|new Mmap VARIABLE, LENGTH, OPTIONALFILENAME||
Maps LENGTH bytes of (the contents of) OPTIONALFILENAME if
OPTINALFILENAME is provided, otherwise uses anonymous, shared
inheritable memory. This memory region is inherited by any fork()ed
children. VARIABLE will now refer to the contents of that file.
Any change to VARIABLE will make an identical change to the file.
If LENGTH is zero and a file is specified, the current length of the
file will be used.
If LENGTH is larger then the file, and OPTIONALFILENAME is
provided, the file is grown to that length before being mapped.
This is the preferred interface, as it requires much less caution
in handling the variable. VARIABLE will be tied into the Mmap
package, and mmap() will be called for you.
Assigning to VARIABLE will overwrite the beginning of the file for a length of the value being assigned in. The rest of the file or memory region after that point will be left intact. You may use substr() to assign at a given position:
substr(VARIABLE, POSITION, LENGTH) = NEWVALUE
|mmap(VARIABLE, LENGTH, PROTECTION, FLAGS, FILEHANDLE, OFFSET)||
Maps LENGTH bytes of (the underlying contents of) FILEHANDLE into your
address space, starting at offset OFFSET and makes VARIABLE refer to
that memory. The OFFSET argument can be omitted in which case it defaults
to zero. The LENGTH argument can be zero in which case a stat is done on
FILEHANDLE and the size of the underlying file is used instead.
The PROTECTION argument should be some ORed combination of the constants PROT_READ, PROT_WRITE and PROT_EXEC or else PROT_NONE. The constants PROT_EXEC and PROT_NONE are unlikely to be useful here but are included for completeness.
The FLAGS argument must include either MAP_SHARED or MAP_PRIVATE (the latter is unlikely to be useful here). If your platform supports it, you may also use MAP_ANON or MAP_ANONYMOUS. If your platform supplies MAP_FILE as a non-zero constant (necessarily non-POSIX) then you should also include that in FLAGS. POSIX.1b does not specify MAP_FILE as a FLAG argument and most if not all versions of Unix have MAP_FILE as zero.
mmap returns undef on failure, and the address in memory where the variable was mapped to on success.
Unmaps the part of your address space which was previously mapped in
with a call to mmap(VARIABLE, ...) and makes VARIABLE become undefined.
munmap returns 1 on success and undef on failure.
|hardwire(VARIABLE, ADDRESS, LENGTH)||Specifies the address in memory of a variable, possibly within a region youve mmap()ed another variable to. You must use the same percaustions to keep the variable from being reallocated, and use substr() with an exact length. If you munmap() a region that a hardwire()ed variable lives in, the hardwire()ed variable will not automatically be undefed. You must do this manually.|
The Mmap module exports the following constants into your namespace
MAP_SHARED MAP_PRIVATE MAP_ANON MAP_ANONYMOUS MAP_FILE
PROT_EXEC PROT_NONE PROT_READ PROT_WRITE
Of the constants beginning MAP_, only MAP_SHARED and MAP_PRIVATE are defined in POSIX.1b and only MAP_SHARED is likely to be useful.
Scott Walters doesnt know XS, and is just winging it. There must be a better way to tell Perl not to reallocate a variable in memory...
The tie() interface makes writing to a substring of the variable much less efficient. One user cited his application running 10-20 times slower when new Mmap is used than when mmap() is called directly.
Malcolm Beattie has not reviewed Scotts work and is not responsible for any bugs, errors, omissions, stylistic failings, importabilities, or design flaws in this version of the code.
There should be a tied interface to hardwire() as well.
Scott Walters spelling is awful.
hardwire() will segfault Perl if the mmap() area it was refering to is munmap()d out from under it.
Todd Rinaldo cleaned up code, modernized again, and merged in many fixes, 2010-2011.
Scott Walters updated for Perl 5.6.x, additions, 2002.
Malcolm Beattie, 21 June 1996.
|perl v5.20.3||MMAP (3)||2014-08-23|