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
2009/9/24 Brandon S. Allbery KF8NH
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.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH