Bryan O'Sullivan ha scritto:
On Thu, Jan 8, 2009 at 1:07 PM, Manlio Perillo <manlio_peri...@libero.it
<mailto:manlio_peri...@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.
How easy is to add support for other methods, like poll, kqueue,
/dev/poll and Windows IOCP?
* 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 personally like Nginx concept of chained buffers.
They are basically a linked list of buffers, where each buffer can be
1) an in memory buffer, where you have pointers to the start, end and
current positions
2) file buffer, where you have a file descriptor and the current file
offset
This is a nice abstraction, since, as an example, a file based buffer
can be sent to the network directly using sendfile.
I think it should fits well with ByteStrings.
* 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.
This is interesting.
Writing clean protocol parsers is one of the things I think Haskell can
be great with.
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.
Well, I have no doubts that good networking can be done in Haskell.
The problem is time.
Erlang (and Twisted, from the Python world) have already years of use.
So, if I need to write *now* a network application, should I *invest* in
Haskell, or should I just *use* Erlang?
As a counter example: I really don't like SQL.
However I have to use it, if I don't want to re-implement a database by
myself.
The same can be said with Fortran.
> [...]
Regards Manlio
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
