1. 17 Feb, 2002 5 commits
  2. 16 Feb, 2002 4 commits
  3. 15 Feb, 2002 19 commits
    • sof's avatar
      [project @ 2002-02-15 22:14:27 by sof] · 9d70000e
      sof authored
      Extra arg to suspendThread() and resumeThread(); controls whether an external call is concurrent or not
      9d70000e
    • sof's avatar
      [project @ 2002-02-15 22:13:32 by sof] · d95869c5
      sof authored
      New call attribute on foreign imports, threadsafe.
      
      It indicates that a foreign import can(*) safely be called
      concurrently with the continued evaluation of other Haskell
      threads, i.e., when the foreign call is made by a Haskell
      thread, it won't hinder the progress of other threads.
      
      (*) - if the platform and RTS supports it, it _will be_
      invoked concurrently.
      d95869c5
    • sof's avatar
      [project @ 2002-02-15 21:07:19 by sof] · d031626e
      sof authored
      comments only
      d031626e
    • sof's avatar
      [project @ 2002-02-15 21:06:29 by sof] · e3fc374f
      sof authored
      fix bug which caused 'safe' to be identical to 'unsafe' in an FFI decl.
      e3fc374f
    • sof's avatar
      [project @ 2002-02-15 20:58:14 by sof] · b7709803
      sof authored
      suspendThread() comment
      b7709803
    • sof's avatar
      [project @ 2002-02-15 17:49:23 by sof] · 21001dc3
      sof authored
      unbreak prev. commit
      21001dc3
    • simonmar's avatar
      [project @ 2002-02-15 14:53:32 by simonmar] · adfe39e8
      simonmar authored
      Ensure that async exceptions are blocked during the raising of an
      async exception - we're about to block them anyway on entry to the
      handler, but we don't want any further exceptions being raised in the
      meantime.
      adfe39e8
    • simonmar's avatar
      [project @ 2002-02-15 14:49:08 by simonmar] · 93d2b952
      simonmar authored
      Fix bugs in async exception raising: instead of trying to build an
      application of the exception handler to the exception directly, just
      leave a THUNK(raise,exception) on top of the CATCH_FRAME ready to
      trigger the next time this thread is run.
      
      This avoids two problems: the PAP we were using before wasn't really a
      PAP, which broke some assumptions elsewhere (c.f. PAP_ENTRY:
      CATCH_FRAME failure), and there was also some duplication between
      raiseAsync and raisezh_fast due to the fact that we were attempting to
      do the raising directly.
      93d2b952
    • sewardj's avatar
      [project @ 2002-02-15 12:29:46 by sewardj] · 5b50dc39
      sewardj authored
      For f-x-dynamic, x86, ccall: rename "a_" to "original_return_addr" so
      that the next luzer to look at this stuff doesn't have to spend hours
      figuring out what the hell "a_" is for.
      5b50dc39
    • simonmar's avatar
      [project @ 2002-02-15 09:46:15 by simonmar] · 92f336f6
      simonmar authored
      Fix typo
      92f336f6
    • simonpj's avatar
      [project @ 2002-02-15 09:32:47 by simonpj] · b383edf2
      simonpj authored
      Comments only
      b383edf2
    • simonpj's avatar
      [project @ 2002-02-15 09:32:18 by simonpj] · 87a229b8
      simonpj authored
      -------------------------------------------------
      	Fix an interesting case-alternatives filtering bug
      	-------------------------------------------------
      
      This bug, shown up by Krasimir's ObjectIO suite, caused the
      simplifier to encounter a case expression like
      	case x of { x:xs -> True; [] -> False }
      in a context where x could not possibly be either a (:) or []!
      Case expressions in the enclosing scope dealt with it...
      So the alternative-filtering removed all the alternatives, leaving
      a case expression with no branches, which GHC didn't like one little
      bit.
      
      The actual bug was elsewhere; it was because we should sometimes
      filter out the DEFAULT alternative, and we weren't doing that.
      To fix it, I pulled the alternative-filtering code out of Simplify
      and put it in SimplUtils.prepareAlts.  It's nice now.
      87a229b8
    • sof's avatar
      [project @ 2002-02-15 08:11:42 by sof] · 98694bb7
      sof authored
      drop -mwin32 filtering
      98694bb7
    • sof's avatar
      [project @ 2002-02-15 08:10:44 by sof] · 1b62ed65
      sof authored
      mingw: drop the use of -mwin32 in CC_OPTS; no longer needed
      1b62ed65
    • sof's avatar
      [project @ 2002-02-15 07:50:36 by sof] · 6d7576ef
      sof authored
      Tighten up the Scheduler synchronisation story some more:
      
      - moved thread_ready_cond + the counter rts_n_waiting_tasks
        to Capability.c, leaving only sched_mutex as a synchro
        variable in Scheduler (the less stuff that inhabit
        Schedule.c, the better, methinks.)
      - upon entry to the Scheduler, a worker thread will now call
        Capability.yieldToReturningWorker() to check whether it
        needs to give up its capability.
      - Worker threads that are either idle or lack a capability,
        will now call Capability.waitForWorkCapability() and block.
      6d7576ef
    • sof's avatar
      [project @ 2002-02-15 07:40:10 by sof] · 22da500c
      sof authored
      Use scheduleExtThread() (see 20020214 commit msg for SchedAPI.h for details)
      22da500c
    • sof's avatar
      [project @ 2002-02-15 07:38:45 by sof] · 9b7c000a
      sof authored
      wibble
      9b7c000a
    • sof's avatar
      [project @ 2002-02-15 07:37:55 by sof] · 619cd23c
      sof authored
      Distinguish between the scheduling of a new thread from within
      the RTS (e.g., via forkIO, running finalizers etc) and scheduling
      of a thread that's created via the RtsAPI -- the latter
      now uses scheduleExtThread(), the rest scheduleThread().
      
      Why the distinction? Because the former will in threaded builds create
      a worker OS thread, while the latter won't. (There's an added
      wrinkle -- main() will also use scheduleThread()).
      619cd23c
    • sof's avatar
      [project @ 2002-02-15 07:23:02 by sof] · c92c7487
      sof authored
      Add rts_mainEvalIO proto
      c92c7487
  4. 14 Feb, 2002 12 commits
    • sof's avatar
      [project @ 2002-02-14 18:20:37 by sof] · f7e5d55c
      sof authored
      more comments
      f7e5d55c
    • sof's avatar
      [project @ 2002-02-14 17:21:50 by sof] · 4acbbe8a
      sof authored
      widen the scope of is_heap_alloced() proto; for all mingw builds
      4acbbe8a
    • sof's avatar
      [project @ 2002-02-14 17:17:08 by sof] · 18b9187c
      sof authored
      COMPILING_RTS wasn't being fed to the C compiler. It is arguably a
      bug/feature deficiency of GHC not to do the Right Thing for invocations
      such as these:
      
         ghc -c -DFOO foo.c
      
      i.e., pass -DFOO to the C compiler -- currently, you have to be explicit
      about this, -optc-DFOO
      18b9187c
    • sof's avatar
      [project @ 2002-02-14 16:58:13 by sof] · fa1ce854
      sof authored
      as per simonpj request, add mingw protos to avoid -Wmissing-declarations warnings
      fa1ce854
    • sof's avatar
      [project @ 2002-02-14 16:55:07 by sof] · 6319ebf3
      sof authored
      resetNonBlockingFd, setNonBlockingFd: mingw tidyup
      6319ebf3
    • sof's avatar
      [project @ 2002-02-14 16:24:59 by sof] · 5f217c8d
      sof authored
      extsBitmap handling: avoid using Int instance for Bits (may not be there; cf. 4.08), use Int32 instead
      5f217c8d
    • simonmar's avatar
      [project @ 2002-02-14 15:51:30 by simonmar] · 0d571ce3
      simonmar authored
      oops, got the sense of an ifdef round the wrong way.
      0d571ce3
    • simonmar's avatar
      [project @ 2002-02-14 15:14:00 by simonmar] · 4f0e92bc
      simonmar authored
      Fixes to 'make install' in fptools/libraries.  We have to maintain the
      directory structure when installing the .hi files, rather than just
      dumping them in a single directory as we do for packages in
      fptools/hslibs.
      4f0e92bc
    • simonmar's avatar
      [project @ 2002-02-14 15:11:28 by simonmar] · 584da9b7
      simonmar authored
      fix typo: PKG_CPP_OPTS ==> PACKAGE_CPP_OPTS (fixes linking libgmp)
      584da9b7
    • simonpj's avatar
      [project @ 2002-02-14 15:08:08 by simonpj] · debf9165
      simonpj authored
      -------------------------------------------------
      	Undo an earlier hack in postInlineUnconditionally
      	-------------------------------------------------
      
      In an earlier era I made postInlineUnconditionally rather less
      aggressive; it didn't inline even trivial things unless they
      occurred just once.  THis was a hack designed to avoid rules
      unexpectedly not firing.  But now we have much more control
      over rules, through the phase numbering stuff, so I can undo the
      hack.
      
      Well, so I believe.  Manuel, yell if your rules stop working!
      debf9165
    • simonpj's avatar
      [project @ 2002-02-14 15:03:38 by simonpj] · 98b23d27
      simonpj authored
      ------------------------------------
      	Desugar existential matches correctly
      	------------------------------------
      
      Consider
      	data T = forall a. Ord a => T a (a->Int)
      
      	f (T x f) True  = ...expr1...
      	f (T y g) False = ...expr2..
      
      When we put in the tyvars etc we get
      
      	f (T a (d::Ord a) (x::a) (f::a->Int)) True =  ...expr1...
      	f (T b (e::Ord a) (y::a) (g::a->Int)) True =  ...expr2...
      
      After desugaring etc we'll get a single case:
      
      	f = \t::T b::Bool ->
      	    case t of
      	       T a (d::Ord a) (x::a) (f::a->Int)) ->
      	    case b of
      		True  -> ...expr1...
      		False -> ...expr2...
      
      *** We have to substitute [a/b, d/e] in expr2! **
      
      
      Originally I tried to use
      	(\b -> let e = d in expr2) a
      to do this substitution.  While this is "correct" in a way, it fails
      Lint, because e::Ord b but d::Ord a.
      
      So now I simply do the substitution properly using substExpr.
      98b23d27
    • simonpj's avatar
      [project @ 2002-02-14 14:56:04 by simonpj] · 6aa2bf20
      simonpj authored
      ---------------------------------------
      	Record updates are ok for types involving
      	existential data constructors, so long as the
      	existential ones aren't the ones updated.
      	---------------------------------------
      
      This check was already in the type checker, but
      the desugarer had an over-zealous assert.
      6aa2bf20