interprocess alternatives and similar packages
Based on the "System" category.
Alternatively, view interprocess alternatives based on common mentions on social networks and blogs.
-
ghc-hotswap
DISCONTINUED. Example code for how we swap compiled code within a running Haskell process. -
plugins
Dynamic linking and runtime evaluation of Haskell, and C, including dependency chasing and package resolution. -
ascii-progress
A simple Haskell progress bar for the console. Heavily borrows from TJ Holowaychuk's Node.JS project -
language-puppet
A library to work with Puppet manifests, test them and eventually replace everything ruby.
InfluxDB – Built for High-Performance Time Series Workloads

Do you think we are missing an alternative of interprocess or a related project?
README
interprocess
Platform-independent interprocess communication.
This project provides a shared memory allocator and some synchronization primitives for Win32 and POSIX systems.
SharedObjectName
Foreign.SharedObjectName.SOName
is a globally unique name that can be used to lookup
shared objects across processes.
Internally, it is a ForeignPtr
to a C-string with a fixed length.
The library provides Eq
, Show
, and Storable
instances and helper functions
to transfer SOName
via pipes or by any other means.
SharedPtr
Foreign.SharedPtr
provides a custom shared memory Allocator
and a bunch of functions
similar to vanilla Ptr
.
Memory allocation is implemented using POSIX mmap and Windows CreateFileMapping APIs.
You can create as many allocators as you want (as your RAM can afford) and
concurrently malloc and free memory in different processes using them.
All functions of that module are wrappers on C functions from Foreign.SharedPtr.C
.
The latter can be used to pass the allocation functions as pointers
(those C functions do not need Haskell runtime, thus can be used in unsafe callbacks).
Control.Concurrent.Process
Control.Concurrent.Process.*
provide a few synchronization primitives trying
to mirror the interface of Control.Concurrent.*
modules for the IPC case.
The behavior is slightly different due to IPC limitations.
Internally, these use semaphore, mutexes, condition variables, and events
from Win32/POSIX in a platform-dependent way.
TODO
- [x]
Foreign.SharedPtr
--malloc
,realloc
andfree
in the shared memory region that can be accessed by multiple processes. - [x] Semaphores
- [x] Mutable variables (
MVar
-like) viaStorable
instance. - [ ]
Control.Concurrent.Chan
-like channels - [ ] More tests
- [ ] Ensure Win32 waiting on events interruptible (Custom interrupt signal handler + WaitForMultipleObjects)
- [ ] Benchmarks
Think about it
There is an untested idea to address GHC stop-the-world GC problem:
- Create several instances of your program in different isolated processes
using e.g.
typed-process
library. - Establish shared memory and semaphore usage via this library
- Garbage collection events in one process do not affect another one at all. Profit!
The question is if the cost of IPC synchronization is lower than the added cost of collecting garbage in all parallel threads.