comp.lang.ada
 help / color / mirror / Atom feed
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Large arrays (again), problem case for GNAT
Date: Thu, 14 Apr 2005 09:29:03 +0200
Date: 2005-04-14T09:29:03+02:00	[thread overview]
Message-ID: <pp53kxqqwpmg.ljc5ufzs8i1r$.dlg@40tude.net> (raw)
In-Reply-To: mailman.30.1113441549.24457.comp.lang.ada@ada-france.org

On Thu, 14 Apr 2005 05:11:56 +0400 (MSD), Alexander E. Kopilovich wrote:

> Robert A Duff wrote;
> 
>> "(see below)" <yaldnif.b@blueyonder.co.uk> writes:
>>
>>> I see that Adrian is using Linux.
>>> Is Linux not notorious for problems of this kind?
>>> 
>>> I seem to remember that it has some kind of optimistic allocator
>> that can grant a memory allocation request, only for it to fail
>> when you try to use the memory you appear to have been granted.
>>
>>...
>>
>> I'm not sure why you say "notorious".  It seems to me that
>> allocate-on-write is desirable.
> 
> So, what is the meaning of malloc call with this approach? In which court
> (somewhere in Linux or outside) I should defend my right to use the memory,
> which I legally requested by malloc, was granted, and then deprived of it?

It is a well known and very old design flaw of many OSes including Linux,
that successful allocation does not give you any amount of virtual memory
until you commit the pages. It is not memory you are granted, it is even
not virtual memory, it is address space which is worth of nothing. This
controversy is as old as in-out parameters of Ada functions...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de



  reply	other threads:[~2005-04-14  7:29 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-13 12:46 Large arrays (again), problem case for GNAT Dr. Adrian Wrigley
2005-04-13 13:10 ` Larry Kilgallen
2005-04-13 13:24   ` Alex R. Mosteo
2005-04-13 13:31   ` Marc A. Criley
2005-04-13 19:52 ` Jeffrey Carter
2005-04-13 19:54 ` Randy Brukardt
2005-04-13 22:01   ` (see below)
2005-04-14  0:16     ` Robert A Duff
2005-04-14  1:11       ` Alexander E. Kopilovich
2005-04-14  7:29         ` Dmitry A. Kazakov [this message]
2005-04-14  7:45           ` Duncan Sands
     [not found]           ` <1113464720.9829.20.camel@localhost.localdomain>
2005-04-14 13:59             ` Marius Amado Alves
2005-04-14 14:09               ` Dr. Adrian Wrigley
2005-04-14 14:40                 ` (see below)
     [not found]             ` <389d1596e98f95f0fdddc40afc0647b7@netcabo.pt>
2005-04-14 14:14               ` Duncan Sands
2005-04-14 15:18         ` Robert A Duff
2005-04-14 15:24           ` Robert A Duff
2005-04-15  5:21             ` Randy Brukardt
2005-04-15 11:49               ` Dr. Adrian Wrigley
2005-04-15 13:21                 ` Dmitry A. Kazakov
2005-04-15 14:31                   ` Dr. Adrian Wrigley
2005-04-15 14:57                     ` Dmitry A. Kazakov
2005-04-14 15:39           ` Dr. Adrian Wrigley
2005-04-14 15:48           ` Dmitry A. Kazakov
2005-04-14 21:19             ` Robert A Duff
2005-04-15  8:23               ` Dmitry A. Kazakov
2005-04-15  8:38                 ` Duncan Sands
2005-04-15  9:16                   ` Dmitry A. Kazakov
2005-04-15 18:30               ` Mark Lorenzen
2005-04-15 19:06                 ` Robert A Duff
     [not found]       ` <iSSDSN2L04G1@VB1162.spb.edu>
2005-04-14  7:34         ` Duncan Sands
2005-04-13 22:35 ` Robert A Duff
2005-04-14 11:40   ` Dr. Adrian Wrigley
2005-04-14 10:44 ` Dr. Adrian Wrigley
2005-04-14 15:03   ` Robert A Duff
2005-04-14 16:46     ` Dmitry A. Kazakov
2005-04-14 18:30       ` Pascal Obry
2005-04-14 19:45         ` Dmitry A. Kazakov
  -- strict thread matches above, loose matches on Subject: below --
2005-04-13 13:52 Duncan Sands
2005-04-13 14:20 ` Dr. Adrian Wrigley
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox