Re: FFI, signals and exceptions

Excerpts from Simon Marlow's message of Tue Aug 31 05:02:13 -0400 2010:
> I think the idea of annotating interruptible calls should be good 
> enough.  Simple blocking system calls like "read" can all be annotated 
> as interruptible without any problems.  Also, pthread_cancel() provides 
> ways to control when cancellation can occur - a thread can say whether 
> it allows cancels at any time or only at cancel points, so that will 
> allow critical sections to be protected, and allow more complicated 
> foreign calls to be made interruptible too.

Gotcha.

> > It seems to me that the obvious thing to do is only allow bound FFI calls
> > to run on bound threads.  What goes wrong with this approach?  Is the
> > waste of threads too severe?
> 
> Not sure what you mean here: what's a bound FFI call?

Good point: we don’t distinguish between FFI calls that require thread
local state and which ones don’t: this might be a good thing to allow
annotating.  If we did know, then we could simply arrange for calls that
use thread-local state to run on those threads, and we would still be
able to farm out other FFI calls as necessary.

A technical question about cleaning up task: when I run freeTask on the
task, I get the following error:

Foo: internal error: invalid closure, info=0xb76fb418
    (GHC version 6.13.20100823 for i386_unknown_linux)

freeTask is only used from freeTaskManager, so I suppose it’s not quite

Re: Confusing warnings from GHC HEAD

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: FFI, signals and exceptions

On 01/09/2010 04:22, Edward Z. Yang wrote:

>> Not sure what you mean here: what's a bound FFI call?
>
> Good point: we don’t distinguish between FFI calls that require thread
> local state and which ones don’t: this might be a good thing to allow
> annotating.  If we did know, then we could simply arrange for calls that
> use thread-local state to run on those threads, and we would still be
> able to farm out other FFI calls as necessary.

Alternatively, "interruptible" could mean "does not use thread-local 
state", which makes sense because in order to interrupt a call we have 
to run it with a disposable thread.

I'm not sure about the mechanism for making a call in another OS thread, 
though.  It might be tricky to implement, because you have to arrange to 
communicate the result somehow.

> A technical question about cleaning up task: when I run freeTask on the
> task, I get the following error:
>
> Foo: internal error: invalid closure, info=0xb76fb418
>      (GHC version 6.13.20100823 for i386_unknown_linux)
>
> freeTask is only used from freeTaskManager, so I suppose it’s not quite
> the right thing to do, however, as far as I can tell GHC doesn’t
> have a current story for freeing tasks.  How should I proceed in figuring
> out the cause of this error?

Right, we don't currently free the Task structure until the end, because 
it caches some timing stats.  This might be something we want to clean 
up in the future.  For now, it would be polite to call workerTaskStop() 
at least for the cancelled Task.

Cheers,
	Simon

RE: Confusing warnings from GHC HEAD

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Compiling base with custom compilation script

I have some custom compilation script that uses GHC API
The aim is to extract some info from every module in dependency graph
and to write this information to the file lying near module-file.
Script goes like this:

main :: IO ()
main =
  do args <- getArgs
     defaultErrorHandler defaultDynFlags $ runGhc (Just libdir) $
       do sdflags <- getSessionDynFlags
          (dflags, fileargs', _) <- parseDynamicFlags sdflags (map noLoc args)
          when (null fileargs') $ ghcError (UsageError "No input files.")
          _ <- setSessionDynFlags dflags
          let fileargs = map unLoc fileargs'
          targets <- mapM (\x -> guessTarget x Nothing) fileargs
          setTargets targets
          mgraph <- depanal [] False
          let files = filter (not . isSuffixOf "boot")
                      . map (extractPath . ms_location) $ mgraph
              extractPath l = fromMaybe (ml_hi_file l) (ml_hs_file l)
          setTargets []
          flip mapM_ files $ \file ->
            do core <- compileToCoreSimplified file
               HscTypes.liftIO $
                    let info = show (generateInfo core)
                        fp = replaceExtension file ".info"
                    putStrLn $ "Writing " ++ fp
                    writeFile fp program

The problem is processing base-4 package. I'd like to run something like:

$ cd base-4.2.0.1
$ compiler -fglasgow-exts -cpp -package-name base -I./include Prelude.hs

and to receive Prelude.info and .info files for every other modules
that prelude depends on.

At first I've got errors like missing .h file. I've downloaded GHC
source distribution and get
missing headers from GHC.

But now I get errors like "trying to load Prelude module which is not
loadable". I don't remember the exact text
and I have no access to my developing-machine. I think it's caused by
circular dependencies between modules.
And I think my compilation script is not quite correct for this case.
What do you think?

--

-- 
Victor Nazarov

Difference between optimized and non-optimized version

Hi!

I am attaching a program which locks (throws an exception <<loop>>)
when compiled like:

ghc --make -threaded -main-is Test.main Test.hs -o test

and doesn't lock when compiled with

ghc --make -threaded -main-is -O2 Test.main Test.hs -o test

This should probably not happen.

I am using 6.12.3 on Linux x86_64.

Best regards

Mitar

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: FFI, signals and exceptions

I cooked up a Darcs patch implementing the new language keyword 'interruptible'
sans tests, Windows support and avoiding executing interruptible calls on bound
worker threads.  However, being a Darcs newbie I ended up sending the patch to
cvs-ghc, not this list.  Let me know if you'd like me to explicitly repost it
here.

Cheers,
Edward

RE: Difference between optimized and non-optimized version

Doesn't look right.  I've made a ticket
	http://hackage.haskell.org/trac/ghc/ticket/4283


Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces <at> haskell.org [mailto:glasgow-haskell-
| users-bounces <at> haskell.org] On Behalf Of Mitar
| Sent: 02 September 2010 01:27
| To: glasgow-haskell-users
| Subject: Difference between optimized and non-optimized version
| 
| Hi!
| 
| I am attaching a program which locks (throws an exception <<loop>>) when
| compiled like:
| 
| ghc --make -threaded -main-is Test.main Test.hs -o test
| 
| and doesn't lock when compiled with
| 
| ghc --make -threaded -main-is -O2 Test.main Test.hs -o test
| 
| This should probably not happen.
| 
| I am using 6.12.3 on Linux x86_64.
| 
| Best regards
| 
| 
| Mitar

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

SIGALRM, SIGVTALRM, and third party libraries

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: SIGALRM, SIGVTALRM, and third party libraries

Excerpts from Bryan O'Sullivan's message of Fri Sep 03 17:00:03 -0400 2010:
> What I am wondering is if there's a practical downside to doing this. Am I
> going to accidentally kill something? This is a very important gap in the
> usability of GHC with native libraries, and if this approach actually turns
> out to be safe in practice, that would be wonderful.

I think the primary downside is that it's not portable (yet) to Windows.  Simon
Marlow and I have been working on "interruptible FFI calls", and one of the
things that needs to be addressed along the way is that the RTS should publish
"portable" equivalents of the pthread functions which are blessed for foreign
libraries to use for this purpose.  Maybe we should emulate threading functionality
at the pthreads layer?

Cheers,
Edward

P.S. I assume that the mysql C bindings are poorly written so as not to work
with alarm signals?