[Haskell-beginners] please critique my first stab at systems programming

Daniel Fischer daniel.is.fischer at googlemail.com
Thu Apr 14 18:21:34 CEST 2011

On Thursday 14 April 2011 17:29:25, Sean Perry wrote:
> Now that I am a little more awake, let me state my requirements more
> clearly to ensure this works as I expect.
> I am hunting through the raw sectors of the disk looking for a sector
> with a specific pattern. "PART" is just a standin for the real thing.
> Since disks are obviously bigger than a meg or two I need to worry
> about space usage. Time performance is important but not as important
> as not reading all 256G of a disk into memory (-:

That's why you'd use a *lazy* ByteString or an Enumerator/Iteratee.

You can have a space leak or leak a file handle with lazy ByteStrings if 
you hold on to parts of the ByteString unnecessary or the compiler doesn't 
detect that the file handle isn't referenced later anymore, but in simple 
situations that is unlikely. So in simple situations using the simpler code 
you get from lazy ByteStrings is reasonable.

I suspect you can also cause leaks with Enumerators and Iteratees, but 
that'll be harder, since avoiding those is the/one point of Enumerators and 

> I need to output the sector number when found. This is why I started
> with the very simple sector by sector search instead of larger chunk
> based one. In my experience the OS tends to read in 4k multiples even
> when you just ask for 512 so there is a buffer somewhere helping with
> performance.

But I think you'd still have a system call with a context switch every 512 
bytes, while if you read in larger chunks you'll have fewer context 
switches and better performance.

> I like your approach Felipe. Thanks. Definitely not something that would
> have been obvious from reading the library docs. I knew there was a
> better way hiding somewhere though. Had I been coding in Python or some
> other language I typically use I would have let Handle be the point of
> abstraction. Anything that looked like a File would work for me.
> The definition of 'go' looks nice and elegant. What does 'the $!i here
> in 'go $! i+1' do?

($!) is strict application, 'go $! i+1' evaluates (i+1) before doing the 
work in go itself, thus preventing the building of a huge thunk

go ((...(0+1)...+1)+1)

More information about the Beginners mailing list