Minimal IPC approach?

[Curt Carpenter]

I have two independent console programs PA and PB.  I want program PB to be able to expose a single boolean value (true or false) to program PA.  The value is to be "read-only" to PA, but can be set and reset at will by PB.  Is there a "best" way to achieve this on linux using as few resource as possible? 

[dbannon]

You could have PB write a "semaphore" file (in eg /tmp) containing either true or false and have PA read it from time to time.

But really, IPC is unquestionably how I would do it.

Davo

[Curt Carpenter]

I was hoping there was some way native to Linux, using environment variables or something, to do this, but if there is I've not been able to discover it.  One idea I had was to let PB create and delete a file of some fixed file path and name, and letting PA use fileexists to decide true or false.  But that seems incredibly clunky.  Can't believe there isn't some core OS way to do this. 

[TRon]

I was hoping there was some way native to Linux

Did someone or something mentioned that there isn't ?

...using environment variables or something

Two completely independent programs one perhaps running in one shell (e.g bash) while the other runs inside another shell (e.g fish). Can't imagine how that would look like.

but if there is I've not been able to discover it.

It is called shared memory, see man shmget

One idea I had was to let PB create and delete a file of some fixed file path and name, and letting PA use fileexists to decide true or false.  But that seems incredibly clunky.

It is. btw there is a directory watcher or something similar that does this for you. Also exist in native form in Linux.

Can't believe there isn't some core OS way to do this.

shared memory or memory mapping. Ergo IPC.

[cdbc]

Hi
As @TRon mentioned DirectoryWatcher, there are also 'Unix-Sockets', regular Tcp-sockets and Memorymapped files i.e.: shared memory, but why not use Simple-Ipc? I think fpc comes with demoes for that...
Regards Benny

[dbannon]

From what I remember, IPC (ie SimpleIPC) from FPC, used dbus to communicate. Cannot get more basic Linux than that.  And you will probably add less lines of code with IPC than semaphore or shem (not counting the code in SimpleIPC if course).

Starting at #400 of https://github.com/tomboy-notes/tomboy-ng/blob/master/source/mainunit.pas  for the 'listener'.

And #160 of https://github.com/tomboy-notes/tomboy-ng/blob/master/source/cli.pas for the 'sender'.

Davo

[Thaddy]

SimpleIPC still works great and does what it says: It is simple to set up, hides complexities and simply works.

[Curt Carpenter]

Thank you for for the inputs.

I've been exploring some ideas following Minsky's book Society of Mind, and have built an "Inter-Process Network" that lets a large number of small independent programs communicate with each other. The network "server" occupies 242KB and a typical "client" about the same depending on what it does, so my old PC can support a respectable number of clients.  I explored SimpleIPC in this use case, but it's too big.  I'm using fcl-net and localhost instead.  The network works, but could be sped up if I had some really cheap way of letting the server notify a client that it "has mail" -- hence the search for a low-overhead one-bit signalling method native to the OS.   

I hadn't thought about trying to use dbus or shmget , but will look into them.   Thanks for the ideas.

[Thaddy]

I would start with what is standard provided, since it is easier to give feedback, ergo:simplefpc. If you require more, one of the other options may be of interest.

[TRon]

... I explored SimpleIPC in this use case, but it's too big.  I'm using fcl-net and localhost instead.  The network works, but could be sped up if I had some really cheap way of letting the server notify a client that it "has mail" -- hence the search for a low-overhead one-bit signalling method native to the OS.   

Provided that pa and pb run on same host with similar permissions the most elementary/simplistic implementation that I am able to come up with for (specifically) a boolean looks like:

Code: Pascal  [Select][+][-]

1. // requires  ctypes, ipc and advancedrecords modeswitch;
2.  
3. type
4.   TSimpleSharedBool = // definition
5.   record
6.    strict private
7.     Fkey   : key_t;
8.     Fid    : cint; // returned identity
9.     Fstore : PBoolean; // actual shared memory integration
10.     procedure AllocateSMS;
11.     procedure AttachSMS;
12.     function GetValue: boolean; // accessible using property
13.     procedure SetValue(aValue: boolean); // accessible using property
14.    public
15.     class function Create(aKey: cint): TSimpleSharedBool; static;
16.     property Value: boolean read GetValue write SetValue; // accessibility barrier
17.   end;
18.  
19. class function TSimpleSharedBool.Create(aKey: cint): TSimpleSharedBool;
20. begin
21.   result.Fkey := aKey; // opening door requires key
22.   result.AllocateSMS; // allocate shared memory segment
23.   result.AttachSMS; // attach shared memory segment
24.   result.FStore^ := false; // inclusion to false
25. end;
26.  
27. procedure TSimpleSharedBool.AllocateSMS;
28. begin
29.   // obtain identity
30.   Fid := shmget(Fkey, sizeOf(boolean), IPC_CREAT or &666); // worship the beast
31.   // check identity status
32.   if (Fid < 0) // if identity undervalued
33.     then halt(1); // abortion
34. end;
35.  
36. {$push}{$warn 4082 off} // disabled warning
37. procedure TSimpleSharedBool.AttachSMS;
38. begin
39.   Fstore := shmat(Fid, nil, 0); // make it belong to shared memory
40.   // check store status
41.   if (PtrInt(Fstore) = PtrInt(-1)) // check for minority equality
42.     then halt(2); // abortion
43. end;
44. {$pop}
45.  
46. function TSimpleSharedBool.GetValue: boolean;
47. begin
48.   result := FStore^; // promote shared to boolean
49. end;
50.  
51. procedure TSimpleSharedBool.SetValue(aValue: boolean);
52. begin
53.   FStore^ := aValue; // promote boolean to shared
54. end;
55.  

... or something to that extend. pa and pb should (ofc) use the same key. Oh, humans should not pay attention to the comments.

[duralast]

The network works, but could be sped up if I had some really cheap way of letting the server notify a client that it "has mail" -- hence the search for a low-overhead one-bit signalling method native to the OS.   

inotify

[MarkMLl]

inotify

That's specifically a wrapper around OS-level notification that a file has changed. It's got its own subtleties, and in the current situation would rely on the two "workers" either updating a file with some underlying locking (left as an exercise...) or creating a file in a directory with a non-colliding name (left as an exercise...). IOW, it creates more problems than it solves.

MarkMLl

[MarkMLl]

...using environment variables or something

Two completely independent programs one perhaps running in one shell (e.g bash) while the other runs inside another shell (e.g fish). Can't imagine how that would look like.

Wouldn't work, since the parent's shell/environment variables are copied to the children hence they don't have update rights.

but if there is I've not been able to discover it.

It is called shared memory, see man shmget

I agree. However a better way- for a simple semaphore or counter- is probably to use a unix-domain socket named like /var/run/PROGNAME, however since this exists in the filesystem namespace one has to be careful with deletion and (re)creation.

You can also use (unix) signals to pass a pointer-sized parameter to a program, I've only played with this a bit but I suspect that the most common usage is to pass a pointer into shared memory.

There's also other possibilities e.g. using the notification facilities that some database servers support.

MarkMLl

[Curt Carpenter]

Thanks to all.  shmget/shmat appears to be exactly what I was looking for.

[Thaddy]

(Humans can read, but dissent)
Anyway: A TEvent and a critical section seems enough.