[lkml]   [1997]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Big mallocs, mmap sorrows and double buffering.
    Matti Aarnio once wrote:
    > It depends -- if the file page is pre-allocated, you can
    > write to it via MAP_SHARED, but you can't extend a file
    > just by overmapping a memory region, and then storeing
    > into those non-backed pages. That is where you will
    > always need write().
    > I recall the `ofd' was opened with O_TRUNC flag, which means
    > it had zero size...
    > In many systems attempt to mmap() [PROT_WRITE, MAP_SHARED] on
    > a file with holes in it (or beyond its end) produces an error.
    > Here we are treading on extremely varying area of system
    > implementations.

    Well, at least under Linux and SunOS mmap()ing a file with a hole looks Ok.
    I usually ftruncate() a file to 2G, do all the mmap()ed I/O I need and then
    ftruncate() it back to an original size. Does anyone know a good reason not
    to support an mmap beyond the end of file?

    _. _ .
    (_ ,_ _ , . / ` _ _L | Email: Oleg Kibirev <>
    ._)| U(_)\/\/ \_,(_L/L | Visit http://math.math.CSUFresno.EDU/~oleg/math.html
    ------------------------' to get my programs + PGP public key

     \ /
      Last update: 2005-03-22 13:38    [W:0.017 / U:49.388 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site