Proposal: add ByteString support to unix:System.Posix.IO API
Bryan O'Sullivan
bos at serpentine.com
Tue Mar 1 07:35:09 CET 2011
On Mon, Feb 28, 2011 at 2:57 PM, wren ng thornton <wren at freegeek.org> wrote:
> So then what would become of the string variants? Backwards compatibility
> and all... not _everyone_ uses ByteStrings yet.
>
If you need the String API, specify a dependency on a version of the package
that still uses String.
Also, FWIW, the real impetus behind writing these was to deal with lazy
> ByteStrings, since that's what one of my dependencies uses[1].
What you really really want, then, is fdWriteAll, which repeatedly uses
writev to write all of a list of strict (or a single lazy) bytestring to an
fd, no? That's why I added sendAll to network-bytestring, because it's
absolutely the common case that you want to write everything you can to a
file descriptor, and not have to worry about short writes.
> It seems
> like a common enough situation that it should be handled directly. Forcing
> people to call (BS.concat . BL.toChunks) first muddies up the code and
> introduces additional copying, whereas making people use (mapM_ fdWrite .
> BL.toChunks) is still rather messy and it's buggy in the face of partial
> writes.
>
Well, wait. That paragraph portion seems to confuse things. At the very
least, it confuses me, because I surely didn't suggest using concat, as that
would be silly. I want to see four entry points for writing:
fdWrite :: Strict.ByteString -> IO Int
fdWriteAll :: Strict.ByteString -> IO ()
fdWritev :: [Strict.ByteString] -> IO Int -- turn the list into an iovec,
then call writev
fdWritevAll :: [Strict.ByteString] -> IO ()
People would normally use the 'All' variants, but there are times when you
really do want to know if you've performed a short write so that you can
handle it yourself.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110228/d7cbb908/attachment.htm>
More information about the Libraries
mailing list