interprocess: Shared memory and control structures for IPC

[ bsd3, library, system ] [ Propose Tags ]

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]
Versions [faq] 0.1.0.0, 0.2.0.0, 0.2.0.1
Dependencies base (>=4.8 && <5), interprocess, typed-process (>=0.2) [details]
License BSD-3-Clause
Copyright (c) 2018 Artem Chirkin
Author Artem Chirkin
Maintainer chirkin@arch.ethz.ch
Category system
Home page https://github.com/achirkin/interprocess
Uploaded by achirkin at Wed Jul 11 09:09:21 UTC 2018
Distributions NixOS:0.2.0.1
Executables wait-mvar, wait-qsem, concurrent-malloc
Downloads 376 total (7 in the last 30 days)
Rating (no votes yet) [estimated by rule of succession]
Your Rating
  • λ
  • λ
  • λ
Status Hackage Matrix CI
Docs available [build log]
Last success reported on 2018-07-11 [all 1 reports]

Modules

[Index]

Flags

NameDescriptionDefaultType
examples

Build example-test programs

DisabledAutomatic
dev

Development build with debugging and with no optimization

DisabledAutomatic

Use -f <flag> to enable a flag, or -f -<flag> to disable that flag. More info

Downloads

Maintainer's Corner

For package maintainers and hackage trustees


Readme for interprocess-0.2.0.1

[back to package description]

interprocess

Hackage Build Status

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 and free in the shared memory region that can be accessed by multiple processes.
  • [x] Semaphores
  • [x] Mutable variables (MVar-like) via Storable 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:

  1. Create several instances of your program in different isolated processes using e.g. typed-process library.
  2. Establish shared memory and semaphore usage via this library
  3. 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.