Hi. After having read http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.h... I have a doubt about Data.ByteString.Lazy. Why getContents function don't use pread (or an emulation, if not available)? Thanks Manlio Perillo
manlio_perillo:
Hi.
After having read http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.h...
I have a doubt about Data.ByteString.Lazy.
Why getContents function don't use pread (or an emulation, if not available)?
Why would it? -- Don
Don Stewart ha scritto:
manlio_perillo:
Hi.
After having read http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.h...
I have a doubt about Data.ByteString.Lazy.
Why getContents function don't use pread (or an emulation, if not available)?
Why would it?
So that you don't need to open the same file multiple time: http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.h...
-- Don
Thanks Manlio Perillo
On Fri, 2008-09-19 at 18:46 +0200, Manlio Perillo wrote:
Don Stewart ha scritto:
manlio_perillo:
Hi.
After having read http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.h...
I have a doubt about Data.ByteString.Lazy.
Why getContents function don't use pread (or an emulation, if not available)?
Why would it?
So that you don't need to open the same file multiple time: http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.h...
We are constrained here by the semantics of Handle which requires that getContents semi-close the Handle (which in turn is to make it harder to shoot yourself in the foot while doing lazy IO). Duncan
Duncan Coutts ha scritto:
On Fri, 2008-09-19 at 18:46 +0200, Manlio Perillo wrote:
Don Stewart ha scritto:
manlio_perillo:
Hi.
After having read http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.h...
I have a doubt about Data.ByteString.Lazy.
Why getContents function don't use pread (or an emulation, if not available)? Why would it?
So that you don't need to open the same file multiple time: http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.h...
We are constrained here by the semantics of Handle which requires that getContents semi-close the Handle (which in turn is to make it harder to shoot yourself in the foot while doing lazy IO).
But if every function that reads the data uses pread, then this should no more be a problem. Or I'm missing some other thing?
Duncan
Manlio Perillo
On Fri, 2008-09-19 at 19:50 +0200, Manlio Perillo wrote:
But if every function that reads the data uses pread, then this should no more be a problem.
Or I'm missing some other thing?
If you used something like pread instead of hGetContents then yes that would not involve semi-closing a handle or doing lazy IO. Of course pread only works for seekable Handles like files, not terminals, pipes, sockets etc etc. Duncan
Manlio Perillo ha scritto:
Hi.
After having read http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.h...
I have a doubt about Data.ByteString.Lazy.
Why getContents function don't use pread (or an emulation, if not available)?
A correction. getContents should not use pread, so the question is: why there is not a hParGetContents Handle -> Integer -> IO ByteString function, where Integer is the absolute file offset where start to read? Thanks Manlio Perillo
participants (3)
-
Don Stewart -
Duncan Coutts -
Manlio Perillo