Thank you,
You give me and idea, and I fixed this annoying bug - we should only wrap all
curl code into withCurlDo function, so the longTask function should be following:
longTask = do
putStrLn "Long task started (curl)"
withCurlDo $ do
curl <- initialize
setopts curl [CurlCookieJar "cookies"]
handle (errorHandler ()) $
mapM_ (\_ -> getSite curl link >> return ()) [0..100]
return ()
Now it works fine and handles interrupts correctly.
Best regards,
Vasyl Pasternak
On Sep 24, 2009, at 06:20 , Brandon S. Allbery KF8NH wrote:On Sep 24, 2009, at 05:30 , Vasyl Pasternak wrote:Yesterday I tried to implement simple tool to download pages, and wanted catch Ctrl-C (and other 'killing' messages) from haskell to handle state saving. Without curl (when I perform some long operation) haskell throws UserInterrupt exception immediately, but if I put long operation, which downloads page from the WEB (from the far-far-away server :) ) than I noticed following issues:
You're going to have problems any time a C library installs its own signal handler, which I would expect libcurl to do so it can clean up after itself. This is true even in C-to-C calling; you need a way to hook the signal handler, which some libraries provide in their API and others you just lose.Just occurred to me I should clarify: while most exception handling mechanisms support the concept of re-throwing exceptions to outer exception handlers, POSIX signals do not. The best you could hope for in a library routine which handles signals itself is an API hook into the signal handler; next best is the API returning a signal-occurred error/exception value.Note that I have no idea how the equivalent signaling mechanism works on Win32.--brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.comsystem administrator [openafs,heimdal,too many hats] allbery@ece.cmu.eduelectrical and computer engineering, carnegie mellon university KF8NH