| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed on the libraries/haskell-cafe mailing lists
http://www.haskell.org/pipermail/libraries/2010-April/013420.html
This is a replacement for block/unblock in the asychronous exceptions
API to fix a problem whereby a function could unblock asynchronous
exceptions even if called within a blocked context.
The new terminology is "mask" rather than "block" (to avoid confusion
due to overloaded meanings of the latter).
In GHC, we changed the names of some primops:
blockAsyncExceptions# -> maskAsyncExceptions#
unblockAsyncExceptions# -> unmaskAsyncExceptions#
asyncExceptionsBlocked# -> getMaskingState#
and added one new primop:
maskUninterruptible#
See the accompanying patch to libraries/base for the API changes.
|
| |
|
|
|
|
|
|
| |
A recent patch ("Refactor CoreArity a bit") changed the arity of
GHC.Conc.runSparks such that it became a CAF, and the RTS was not
explicitly retaining it, which led to a crash when the CAF got GC'd.
While fixing this I found a couple of other closures that the RTS
refers to which weren't getting the correct CAF treatment.
|
| | |
|
| |
|
|
|
| |
Also add a panic for resurrecting a thread blocked on an exception,
since it should never happen.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The API is the same (for now). The new implementation has the
capability to define signal handlers that have access to the siginfo
of the signal (#592), but this functionality is not exposed in this
patch.
#2451 is the ticket for the new API.
The main purpose of bringing this in now is to fix race conditions in
the old signal handling code (#2858). Later we can enable the new
API in the HEAD.
Implementation differences:
- More of the signal-handling is moved into Haskell. We store the
table of signal handlers in an MVar, rather than having a table of
StablePtrs in the RTS.
- In the threaded RTS, the siginfo of the signal is passed down the
pipe to the IO manager thread, which manages the business of
starting up new signal handler threads. In the non-threaded RTS,
the siginfo of caught signals is stored in the RTS, and the
scheduler starts new signal handler threads.
|
| |
|
|
|
| |
Signficantly reduces the overhead for par, which means that we can
make use of paralellism at a much finer granularity.
|
| |
|
|
|
| |
We now need to make sure that they have been toException'd.
Also, the RTS doesn't know about the Deadlock exception any more.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We now use a nonTermination value in the base library to take take of
constructing the SomeException value, with the dictionaries etc, for us.
We'll probably need to do the same for some other exceptions too
|
| |
|
|
|
| |
Integer, Bool and Unit/Inl/Inr are now in new packages integer
and ghc-prim.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #637.
The implications of this change are:
- threadDelay on Windows no longer creates a new OS thread each time,
instead it communicates with the IO manager thread in the same way as
on Unix.
- deadlock detection now works the same way on Windows as on Unix; that
is the timer interrupt wakes up the IO manager thread, which causes
the scheduler to check for deadlock.
- Console events now get sent to the IO manager thread, in the same way as
signals do on Unix. This means that console events should behave more
reliably with -threaded on Windows.
All this applies only with -threaded. Without -threaded, the old
ConsoleEvent code is still used.
After some testing, this could be pushed to the 6.6 branch.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the threaded RTS on *nix platforms:
- we now start the IO manager thread eagerly at startup time
(previously was started on demand).
- we now ask the IO manager thread to stop at shutdown
- In Timer.c:handle_tick, if it looks like we might be in a
deadlock, instead of calling prodOneCapability() which was known to be
wrong, we now send a byte down the IO manager's pipe to wake it up.
This also avoids a case of double-acquisition of a mutex, which
happened if prodOneCapability() was called while the current thread
was holding a mutex.
|
|
|
Most of the other users of the fptools build system have migrated to
Cabal, and with the move to darcs we can now flatten the source tree
without losing history, so here goes.
The main change is that the ghc/ subdir is gone, and most of what it
contained is now at the top level. The build system now makes no
pretense at being multi-project, it is just the GHC build system.
No doubt this will break many things, and there will be a period of
instability while we fix the dependencies. A straightforward build
should work, but I haven't yet fixed binary/source distributions.
Changes to the Building Guide will follow, too.
|
