Proposal: add ByteString support to unix:System.Posix.IO API

Bryan O'Sullivan bos at
Tue Mar 1 07:35:09 CET 2011

On Mon, Feb 28, 2011 at 2:57 PM, wren ng thornton <wren at> 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: <>

More information about the Libraries mailing list