summaryrefslogtreecommitdiff
path: root/rts/posix/OSThreads.c
Commit message (Collapse)AuthorAgeFilesLines
...
* Interruptible FFI calls with pthread_kill and CancelSynchronousIO. v4Edward Z. Yang2010-09-191-0/+10
| | | | | | | | | | | | | | | | | | | | | | | This is patch that adds support for interruptible FFI calls in the form of a new foreign import keyword 'interruptible', which can be used instead of 'safe' or 'unsafe'. Interruptible FFI calls act like safe FFI calls, except that the worker thread they run on may be interrupted. Internally, it replaces BlockedOnCCall_NoUnblockEx with BlockedOnCCall_Interruptible, and changes the behavior of the RTS to not modify the TSO_ flags on the event of an FFI call from a thread that was interruptible. It also modifies the bytecode format for foreign call, adding an extra Word16 to indicate interruptibility. The semantics of interruption vary from platform to platform, but the intent is that any blocking system calls are aborted with an error code. This is most useful for making function calls to system library functions that support interrupting. There is no support for pre-Vista Windows. There is a partner testsuite patch which adds several tests for this functionality.
* Add thread affinity support for FreeBSDGabor Pali2010-07-201-2/+31
| | | | | | | | | - Implement missing functions for setting thread affinity and getting real number of processors. - It is available starting from 7.1-RELEASE, which includes a native support for managing CPU sets. - Add __BSD_VISIBLE, since it is required for certain types to be visible in addition to POSIX & C99.
* RTS tidyup sweep, first phaseSimon Marlow2009-08-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Please the -Wall police by moving a variable declaration; really FIX ↵Austin Seipp2009-03-201-1/+1
| | | | getNumberOfProcessors() for MacOS X
* FIX getNumberOfProcessors() on MacOS XAustin Seipp2009-03-181-0/+9
| | | | | This checks if darwin_HOST_OS is defined and, if so, we call sysctlbyname() on the "hw.ncpu" property to get the processor count.
* Fix bug in setThreadAffinity() (Linux)Simon Marlow2009-03-201-1/+1
|
* Implement setThreadAffinity for Mac OS X (from 10.5)Manuel M T Chakravarty2009-03-201-2/+27
|
* wibble for getNumberOfProcessorsSimon Marlow2009-03-181-0/+4
|
* Set thread affinity with +RTS -qa (only on Linux so far)Simon Marlow2009-03-181-1/+26
|
* Add getNumberOfProcessors(), FIX MacOS X build problem (hopefully)Simon Marlow2009-03-171-0/+18
| | | | | Somebody needs to implement getNumberOfProcessors() for MacOS X, currently it will return 1.
* Always use PTHREAD_MUTEX_ERRORCHECK to create mutexes when -DDEBUGIan Lynagh2009-01-181-4/+0
| | | | | Linux defines PTHREAD_MUTEX_ERRORCHECK = PTHREAD_MUTEX_ERRORCHECK_NP anyway, so there's no need to special-case it.
* Use error-checking mutexes on all platforms when DEBUG is onIan Lynagh2009-01-171-1/+5
| | | | Otherwise ASSERT_LOCK_HELD will cause deadlocks
* pthread_key_delete wants the key itself, not a pointer to itIan Lynagh2007-02-231-1/+1
|
* Free thread local storage on shutdownIan Lynagh2007-02-221-0/+9
|
* Warning police: Avoid warning about unused variablesven.panne@aedion.de2007-02-011-1/+1
|
* Partial fix for #926Simon Marlow2007-02-011-0/+8
| | | | | | | | | | | | | | 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.
* Add closeMutex and use it on clean upEsa Ilari Vuokko2006-08-231-0/+5
|
* Gather timing stats for a Task when it completes.Simon Marlow2006-06-071-0/+2
| | | | | Previously we did this just for workers, now we do it for the main thread and for forkOS threads too.
* Reorganisation of the source treeSimon Marlow2006-04-071-0/+166
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.
View Lorry Controller Status