[Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical
Haskell job in New York]
Bryan O'Sullivan
bos at serpentine.com
Thu Jan 8 18:34:00 EST 2009
On Thu, Jan 8, 2009 at 1:07 PM, Manlio Perillo <manlio_perillo at libero.it>wrote:
> Another example is the multipart parser:
>
> -- | Read a multi-part message from a 'Handle'.
> -- Fails on parse errors.
> hGetMultipartBody :: String -- ^ Boundary
> -> Handle
> -> IO MultiPart
> hGetMultipartBody b h =
> do
> s <- BS.hGetContents h
> case parseMultipartBody b s of
> Nothing -> fail "Error parsing multi-part message"
> Just m -> return m
>
Yes, that's definitely on the scary side of things.
However, you don't have to go all the way to drinking the Iteratee Kool-Aid
in order to write safer networking code that is still performant. Here are a
few projects I'm actively working on in this area:
- I'm adding epoll support to the threaded RTS. This is a necessity for
server performance.
- I've added support for sending and receiving lazy ByteStrings to Johan
Tibbell's network-bytestring library. A quick benchmark with a toy HTTP
server has shown this to be about 2x faster than writing ByteStrings to a
Handle (i.e. 14,000 requests per second, vs 7,000).
- I've got a continuation-based resumable parser combinator module for
attoparsec in progress, which uses lazy ByteStrings for blazing performance.
You can use this to write protocol parsers in a completely clean way,
decoupled from the underlying network receive operations.
While much of this isn't quite ready for use yet, this just represents one
person's work, and there are lots of people beavering away actively at
corners of the problem space that interest them.
I actually think that we're very close to being in fantastic shape here. I'm
working on a memcached client library that uses the above libraries, and
it's faster than the absolute best C memcached client (libmemcached), while
also far smaller and elegantly layered. As a community, we are developing
many proofs that you can have beautiful code without sacrificing
performance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090108/ffebdfb4/attachment.htm
More information about the Haskell-Cafe
mailing list