| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The file rts/win32/libHSbase.def contains a list of all the
symbols from the base library that the RTS needs.
When building the RTS into a DLL on Windows, we want to link the DLL
for the RTS before we link the DLL for the base library. We use
libHSbase.def to make the "import library" libHSbase.so.a, which
contains stubs for each of the symbols from the base library that
the RTS needs.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
Somebody needs to implement getNumberOfProcessors() for MacOS X,
currently it will return 1.
|
| |
|
|
|
|
|
|
|
| |
Evidently I misread the docs for CreateEvent: if you pass a name to
CreateEvent, then it creates a single shared system-wide Event with
that name. So all Haskell processes on the machine were sharing the
same Event object. duh.
|
| |
|
| |
|
|
|
|
| |
Fixes "invalid what_next field" in ioref001 on Windows, and perhaps others
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
2301: Control-C now causes the new exception (AsyncException
UserInterrupt) to be raised in the main thread. The signal handler
is set up by GHC.TopHandler.runMainIO, and can be overriden in the
usual way by installing a new signal handler. The advantage is that
now all programs will get a chance to clean up on ^C.
When UserInterrupt is caught by the topmost handler, we now exit the
program via kill(getpid(),SIGINT), which tells the parent process that
we exited as a result of ^C, so the parent can take appropriate action
(it might want to exit too, for example).
One subtlety is that we have to use a weak reference to the ThreadId
for the main thread, so that the signal handler doesn't prevent the
main thread from being subject to deadlock detection.
1619: we now ignore SIGPIPE by default. Although POSIX says that a
SIGPIPE should terminate the process by default, I wonder if this
decision was made because many C applications failed to check the exit
code from write(). In Haskell a failed write due to a closed pipe
will generate an exception anyway, so the main difference is that we
now get a useful error message instead of silent program termination.
See #1619 for more discussion.
|
| |
|
|
|
|
|
|
|
|
|
| |
- GCAux.c contains code not compiled with the gct register enabled,
it is callable from outside the GC
- marking functions are moved to their relevant subsystems, outside
the GC
- mark_root needs to save the gct register, as it is called from
outside the GC
|
|
|
|
| |
For clients that forget to do hs_add_root()
|
| |
|
| |
|
|
|
|
| |
Also common-up some duplicate bits in the platform-specific code
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Having a timer signal go off regularly is bad for power consumption,
and generally bad practice anyway (it means the app cannot be
completely swapped out, for example). Fortunately the threaded RTS
already had a way to detect when the system was idle, so that it can
trigger a GC and thereby find deadlocks. After performing the GC, we
now turn off timer signals, and re-enable them again just before
running any Haskell code.
|
|
|
|
|
|
| |
The C-- parser was missing the "stdcall" calling convention for
foreign calls, but once added we can call {Enter,Leave}CricialSection
directly.
|
| |
|
|
|
|
|
| |
When calling EnterCriticalSection and LeaveCriticalSection from C--
code, we go via wrappers which use ccall (rather than stdcall).
|
|
|
|
|
|
|
|
|
|
|
| |
Now we don't wait for outstanding IO requests when shutting down at
program exit time, but we still wait when shutting down a DLL (via
hs_exit()). There ought to be a better way to do this, but
terminating the threads forcibly is not a good idea (it never is: the
thread might be holding a mutex when it dies, for example).
I plan to add some docs to the user guide to describe how to shut
down a DLL properly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This lets the threaded RTS use SIGVTALRM rather than SIGALRM for its
interval timer signal, so the threaded and non-threaded RTS are
compatible. It unfortunately doesn't completely fix #850/#1156, for
that we really have to use a restartable sleep instead of usleep().
Also I cleaned up the timer API a little: instead of returning an
error value that ultimately gets ignored, we now report errors from
system calls and exit.
|
| |
|
|
|
|
|
| |
This is the Windows counterpart to "Make the non-threaded-RTS
threadDelay wait at least as long as asked"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It seems that when a program exits with open DLLs on Windows, the
system attempts to shut down the DLLs, but it also terminates (some
of?) the running threads. The RTS isn't prepared for threads to die
unexpectedly, so it sits around waiting for its workers to finish.
This bites in two places: ShutdownIOManager() in the the unthreaded
RTS, and shutdownCapability() in the threaded RTS. So far I've
modified the latter to notice when worker threads have died
unexpectedly and continue shutting down. It seems a bit trickier to
fix the unthreaded RTS, so for now the workaround for #926 is to use
the threaded RTS.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
It isn't used here anyway, just making sure the code doesn't get compiled in.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
To avoid IO requests completing only to discover that the
completed_table_sema has been CloseHandle()'d. This all looks a bit
wrong, though: we shouldn't really be waiting for these requests to
complete, they might take forever.
|
| |
|
| |
|
|
|
|
| |
patch from #878
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There's no need to mark the signal handler here, because it is stored
in a StablePtr and hence is a root anyway. Furthermore, the call to
evac() was passing the address of a local variable, which turned out
to be harmless for copying GC, but fatal for compacting GC: compacting
GC assumes that the addresses of the roots are the same each time.
Fixes: possibly #783, possibly #776, definitely #787
|
| |
|