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 Iteratees.
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)