| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first phase of this tidyup is focussed on the header files, and in
particular making sure we are exposinng publicly exactly what we need
to, and no more.
- Rts.h now includes everything that the RTS exposes publicly,
rather than a random subset of it.
- Most of the public header files have moved into subdirectories, and
many of them have been renamed. But clients should not need to
include any of the other headers directly, just #include the main
public headers: Rts.h, HsFFI.h, RtsAPI.h.
- All the headers needed for via-C compilation have moved into the
stg subdirectory, which is self-contained. Most of the headers for
the rest of the RTS APIs have moved into the rts subdirectory.
- I left MachDeps.h where it is, because it is so widely used in
Haskell code.
- I left a deprecated stub for RtsFlags.h in place. The flag
structures are now exposed by Rts.h.
- Various internal APIs are no longer exposed by public header files.
- Various bits of dead code and declarations have been removed
- More gcc warnings are turned on, and the RTS code is more
warning-clean.
- More source files #include "PosixSource.h", and hence only use
standard POSIX (1003.1c-1995) interfaces.
There is a lot more tidying up still to do, this is just the first
pass. I also intend to standardise the names for external RTS APIs
(e.g use the rts_ prefix consistently), and declare the internal APIs
as hidden for shared libraries.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has several advantages:
- -fvia-C is consistent with -fasm with respect to FFI declarations:
both bind to the ABI, not the API.
- foreign calls can now be inlined freely across module boundaries, since
a header file is not required when compiling the call.
- bootstrapping via C will be more reliable, because this difference
in behavour between the two backends has been removed.
There is one disadvantage:
- we get no checking by the C compiler that the FFI declaration
is correct.
So now, the c-includes field in a .cabal file is always ignored by
GHC, as are header files specified in an FFI declaration. This was
previously the case only for -fasm compilations, now it is also the
case for -fvia-C too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The hs_hpc_module() prototype in RtsExternal.h didn't match its usage:
we were passing StgWord-sized parameters but the prototype used C
ints. I think it accidentally worked because we only ever passed
constants that got promoted. The constants unfortunately were
sometimes negative, which caused the C compiler to emit warnings.
I suspect PprC.pprHexVal may be wrong to emit negative constants in
the generated C, but I'm not completely sure. Anyway, it's easy to
fix this in CgHpc, which is what I've done.
|
| |
|
|
| |
Fixes some gratuitous warnings when compiling via C with -fhpc
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously MVars were always on the mutable list of the old
generation, which meant every MVar was visited during every minor GC.
With lots of MVars hanging around, this gets expensive. We addressed
this problem for MUT_VARs (aka IORefs) a while ago, the solution is to
use a traditional GC write-barrier when the object is modified. This
patch does the same thing for MVars.
TVars are still done the old way, they could probably benefit from the
same treatment too.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
foreign import ccall unsafe hs_hpc_write :: CString -> IO ()
foreign import ccall unsafe hs_hpc_read :: CString -> IO ()
These write a Hpc description of the state of the world to a file,
or read a description into the current Hpc tickbox subsystem.
|
| |
|
|
|
|
|
|
|
|
| |
When -fbreak-on-exception is set, an exception will cause GHCi to
suspend the current computation and return to the prompt, where the
history of the current evaluation can be inspected (if we are in
:trace). This isn't on by default, because the behaviour could be
confusing: for example, ^C will cause a breakpoint. It can be very
useful for finding the cause of a "head []" or a "fromJust Nothing",
though.
|
| |
|
|
|
|
|
|
|
| |
- .tix files are now a list of MixModule, which contain a hash of the contents of the .mix file.
- .mix files now have (the same) hash number.
This changes allow different binaries that use the same module compiled in the same way
to share coverage information.
|
| |
|
|
| |
HANDLE is defined to be (void *) anyway, so this shouldn't hurt
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
- Added HPCRIX support for passing tracer filename.
- Added thread tracing support.
- Cleaned up use of HsFFI.h
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 preparation for parallel GC, split up the monolithic GC.c file into
smaller parts. Also in this patch (and difficult to separate,
unfortunatley):
- Don't include Stable.h in Rts.h, instead just include it where
necessary.
- consistently use STATIC_INLINE in source files, and INLINE_HEADER
in header files. STATIC_INLINE is now turned off when DEBUG is on,
to make debugging easier.
- The GC no longer takes the get_roots function as an argument.
We weren't making use of this generalisation.
|
| |
|
|
|
|
|
| |
I don't think this can ever be useful, because to add more roots you
need to do it consistently for every GC. The right way to add roots
is to use newStablePtr.
|
| | |
|
| | |
|
|
|
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.
|
