Hi David, Re: this comment from catchI:
> It is not possible to catch asynchronous exceptions, such as lazily evaluated > divide-by-zero errors, the throw function, or exceptions raised by other > threads using throwTo if those exceptions might arrive anywhere outside of a > liftIO call. It might be worth investigating providing a version which can catch asynchronous exceptions if the underlying monad supports it (via MonadCatchIO or something similar). One of the most interesting advantages I can see for IterIO over the other iteratee implementations is that you actually have some control over resource usage -- not being able to catch asynchronous exceptions nullifies much of that advantage. A clear use case for this is timeouts on server threads, where you typically throw a TimeoutException exception to the handling thread using "throwTo" if the timeout is exceeded. Another question re: resource cleanup: in the docs I see: > Now suppose inumHttpBody fails (most likely because it receives an EOF before > reading the number of bytes specified in the Content-Length header). Because > inumHttpBody is fused to handler, the failure will cause handler to receive > an EOF, which will cause foldForm to fail, which will cause handleI to > receive an EOF and return, which will ensure hClose runs and the file handle > h is not leaked. > Once the EOFs have been processed, the exception will propagate upwards > making inumHttpServer fail, which in turn will send an EOF to iter. Then the > exception will cause enum to fail, after which sock will be closed. In > summary, despite the complex structure of the web server, because all the > components are fused together with pipe operators, corner cases like this > just work with no need to worry about leaked file descriptors. Could you go into a little bit of detail about the mechanism behind this? Thanks! G -- Gregory Collins <g...@gregorycollins.net> _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
