ByteString I/O Performance

[Donald Bruce Stewart]

seth:
> 
> 
> -----Original Message-----
> From: Donald Bruce Stewart [mailto:dons at cse.unsw.edu.au] 
> Sent: Monday, September 03, 2007 12:03 AM
> To: Seth Kurtzberg
> Cc: libraries at haskell.org
> Subject: Re: ByteString I/O Performance
> 
> seth:
> > 
> > 
> > -----Original Message-----
> > From: libraries-bounces at haskell.org [mailto:libraries-bounces at haskell.org]
> On Behalf Of Bryan O'Sullivan
> > Sent: Sunday, September 02, 2007 11:23 PM
> > To: Peter Simons
> > Cc: libraries at haskell.org
> > Subject: Re: ByteString I/O Performance
> > 
> > Peter Simons wrote:
> > 
> > > One way to get malloc() out of the picture would be to provide a
> > > variant of hGet that takes an existing, pre-allocated buffer as an
> > > argument, so that the user can allocate a ByteString once and re-use
> > > it for every single hGet and hPut.
> > 
> > This is already quite easy to do.  See unsafeUseAsCStringLen in 
> > Data.ByteString.Base, and hGetBuf in System.IO.
> > 
> > Is it possible without resorting to an unsafeXXX function?
> 
> They're all 'unsafe' for different reasons :) 
> The question should be: why is this unsafe? 
> 
> (It's unsafe because it doesn't copy the C string, so you need to have a
> side condition that the string isn't modified by C).
> 
> OK.  Assume that I'm not doing any C coding, so that the only C code that is
> invoked is called from within the implementation (in this case the
> implementation of System.IO).  Can I assume that no implementation code
> modifies the string?  In other words, is it valid to assume that the side
> condition is never violated so long as I don't violate the side condition in
> my own C code (if any)?
> 

Yes, that's right. Its safe as long as you don't modify the string
yourself in C.

-- Don