Obsolete
/
libipc-old
Archived
3
0
Fork 0
Code

Presentation of LibIPC: a few improvements.

master
Philippe Pittoli 2023-01-20 04:49:45 +01:00
parent 06a01f2b4b
commit 82f81a7fb7
1 changed files with 35 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
docs/libipc.md
View File

@ -11,17 +11,40 @@ Network code separation
* networking: performed by dedicated services * networking: performed by dedicated services
* other applications: think all communications are local * other applications: think all communications are local
#pause
Library code separation Library code separation
* make libraries language independent * make libraries language independent
* micro-services are great, each of them does its part * micro-services are great, each of them does its part
#pause
why not on base systems? why not on base systems?
#pause
Applications are better than libraries Applications are better than libraries
* implementations change * implementations change
* languages change * languages change
* API… not so much (not as often at least) * API… not so much (not as often at least)
## In practice
usage must be simple
1. init connection or service
2. loop over events
#pause
events are simple and high level
1. connection and disconnection
2. message received and sent
## When
LibIPC is useful when the app:
- cannot be a simple shell command
- needs a bidirectional communication
- is an abstraction over a library
## Available libraries ## Available libraries
* libevent * libevent
@ -54,22 +77,23 @@ Is it designed *NOT* to be used?
* documentation isn't great * documentation isn't great
* no code example * no code example
And kinda obsolete: a big chunk of the documentation is ## DBUS (bonus page!)
DBUS feels obsolete: a big chunk of the documentation is
about message format. Just use CBOR already! about message format. Just use CBOR already!
#pause
They even admit they did a poor job on the C part: They even admit they did a poor job on the C part:
> There is a low-level C binding, but that is probably too detailed > There is a low-level C binding, but that is probably too detailed
> and cumbersome for anything but writing other bindings. > and cumbersome for anything but writing other bindings.
#pause
Oh. And C++. YOU SHALL NOT PASS! Oh. And C++. YOU SHALL NOT PASS!
This is a Linux requirement nowadays, wth? This is a Linux requirement nowadays, wth?
## Bare libc api ## Bare libc api
All have great performances
shared memory and semaphores shared memory and semaphores
* (kinda) complicated api * (kinda) complicated api
@ -80,8 +104,11 @@ pipes, sockets
* lack a conventional message format * lack a conventional message format
... but that's about it ... but that's about it
Great to start with! * Great to start with!
All have great performances to exchange data.
What is slow is the function to _wait_ for new events.
## LibIPC history ## LibIPC history
@ -100,17 +127,11 @@ pipes, sockets
#pause #pause
3. rewrite using poll(2) 3. rewrite using poll(2)
* many bugfixes later, way more tested than before * many bugfixes later, way more tested than before
* implementation now kinda production-ready * implementation was kinda production-ready
* enough for altideal.com at least * implementation was simple: < 2000 lines of C code
## Current implementation of libIPC ## Current implementation of libIPC
implementation is simple: < 2000 lines of C code
usage is simple
1. init connection or server
2. loop over events
bindings are available in Crystal bindings are available in Crystal
* as well as fancy mappings: JSON and CBOR class serialization * as well as fancy mappings: JSON and CBOR class serialization