On Tue, Mar 29, 2011 at 2:37 AM, Edward Z. Yang <ezy...@mit.edu> wrote:
> Excerpts from Jason Dagit's message of Tue Mar 29 00:43:10 -0400 2011: > > I was reading up on the documentation for alloca and friends[1], which > says, > > "If any of the allocation functions fails, a value of > > nullPtr< > http://www.haskell.org/ghc/docs/7.0.2/html/libraries/base-4.3.1.0/Foreign-Ptr.html#v:nullPtr > > > > is > > produced." > > > > It seems like every example of FFI code that I find which uses alloca > > ignores the possibility of a nullPtr[2, 3, 4]. > > > > So then I started trying out examples with the help of dmwit and others > from > > #haskell. > > > > It seems that actually, alloca and friends throw exceptions: > > dmwit> main = allocaArray (2^30) (\ptr -> print ((nullPtr :: Ptr Double) > == > > ptr)) > > <dmwit> lispy: alloca also throws an exception. > > <dmwit> lispy: Or rather, allocaBytes throws an exception, and alloca is > > implemented in terms of allocaBytes, so I'm *guessing* that alloca throws > an > > exception. > > > > I'm on a 64bit version of windows here with more than 4GB of memory to > spare > > for the GHC process. Unfortunately, allocaBytes takes an Int so I can't > test > > it with a request larger than the amount of physical ram I have. > > You could try testing by setting different limits on the memory usage of > your > process with ulimit. I'll give a test, but the prevailing wisdom is that if > you > OOM, you're really out of luck. > I just want to be clear: You can get alloca and friends to fail well BEFORE you are OOM. Just allocate something larger than the remaining contiguous space. If you're allocating a few KB and you run out of memory that can be bad situation, but I don't think we should treat all allocation failures as if the sky is falling :) Jason
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
