interprocess: Shared memory and control structures for IPC
Provides portable shared memory allocator and some synchronization primitives. Can be used for interprocess communication. Refer to README.md for further information.
[Skip to Readme]
Modules
[Index] [Quick Jump]
Flags
Manual Flags
| Name | Description | Default |
|---|---|---|
| examples | Build example-test programs | Disabled |
| dev | Development build with debugging and with no optimization | Disabled |
Use -f <flag> to enable a flag, or -f -<flag> to disable that flag. More info
Downloads
- interprocess-0.2.1.0.tar.gz [browse] (Cabal source package)
- Package description (as included in the package)
Maintainer's Corner
For package maintainers and hackage trustees
Candidates
- No Candidates
| Versions [RSS] | 0.1.0.0, 0.2.0.0, 0.2.0.1, 0.2.1.0 |
|---|---|
| Dependencies | base (>=4.8 && <5), interprocess, typed-process (>=0.2.5) [details] |
| License | BSD-3-Clause |
| Copyright | (c) 2018-2022 Artem Chirkin |
| Author | Artem Chirkin |
| Maintainer | achirkin@users.noreply.github.com |
| Category | system |
| Home page | https://github.com/achirkin/interprocess |
| Uploaded | by achirkin at 2022-07-02T15:51:55Z |
| Distributions | NixOS:0.2.1.0 |
| Reverse Dependencies | 1 direct, 0 indirect [details] |
| Executables | wait-mvar, wait-qsem, concurrent-malloc |
| Downloads | 1933 total (7 in the last 30 days) |
| Rating | (no votes yet) [estimated by Bayesian average] |
| Your Rating | |
| Status | Docs available [build log] Last success reported on 2022-07-02 [all 1 reports] |
Readme for interprocess-0.2.1.0
[back to package description]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
-
Foreign.SharedPtr--malloc,reallocandfreein the shared memory region that can be accessed by multiple processes. -
Semaphores
-
Mutable variables (
MVar-like) viaStorableinstance. -
Control.Concurrent.Chan-like channels -
More tests
-
Ensure MVar waits are interruptible w.r.t. async exceptions on all platforms
-
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-processlibrary. - 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.