[fpc-devel] Inter Process Communication

[Jason P Sage]

> > > > Does the IPC unit written for linux by Michael Van Canneyt now
support other
> > > > platforms?
> > > 
> > > It supports windows as well. Since day 1, I might add.
> > 
> > I only see an implementation on unit ipc in the rtl/unix directory.
>
> He means simpleipc in the fcl, I assume ?
> 
> Michael.


Thank you for your comments gentlemen.

My findings thus far are that the simpleipc is the only "portable" and
available unit for inter-process communication I see in the 2.0.4
distribution. 

The ipc unit itself isn't even "available" for Win32 platform in my copy of
2.0.4. 

Looking at the code for simpleipc, thus far, I get the impression that
descendant classes need to written in a special way if I want to extend the
class further. I'm referring to the code like this:


---SNIPPET--BEGIN

constructor TIPCServerComm.Create(AOwner: TSimpleIPCServer);
begin
  FOwner:=AOWner;
end;

---SNIPPET--END

There is procedure defined in TSimpleIPCClient named: 
    Procedure SendStringMessage(Msg : String);

And a mate function defined in TSimpleIPCServer named 
    function GetStringMessage: String;

If I could add a new pair of functions to the fcl simpleipc unit such as :
SendAnsiString and GetAnsiString I could probably accomplish what I am
trying to do without needing to make a descendant.

I would like to be able to arbitrarily send messages as small as one byte to
a megabyte at a time. 

One example is with my Jegas Information Server, a CGI program. 

The CGI program (the cgi thin client.. rather tiny in win32- 50k bytes)
gathers all the CGI environment information and saves it to a binary file
with a unique id for a file name and waits for a response output file - 
Ultimately a web page or page redirect or something.

The Jegas Information Server has idle - threads to handle responding to the
web requests that come in. When it sees a new file come in to be processed,
it loads the data - prepares the thread - and away it goes. Effectively
creating the output that the CGI thin client is waiting for.

I understand that if I made my own "simpleipc" class - (which has platform
specific code in the *.inc files) that I can make my own message types etc.

I also know that if I could just send ansistrings back and forth, I can do
ansistring magic (I love FreePascal ansistrings... have I said that?) where
I may stack a bunch of data in one long byte sequence that the receiver can
decipher and make sense of. 


For example - Stack multiple ansistring values into one long ansistring -
with a means to tell where each begins and end - effectively allowing this
arbitrary amount of data to be sent in one message eliminating semaphore
code overhead processing a bunch of little messages.

Even this would require overhead - where as set message definations may be a
better solution - which - to my knowledge implies writing my own simpleipc
unit by a different name, and then writing the code the Win32 implementation
and then the unix implementation myself.

So - I guess I'm asking a couple things:

1: Would anyone would be opposed to me extending the simpleipc class
minimally - and submitting it to the fcl for distribution - so that it has
the two new procedures/function mentioned above? (which I would need to know
the procedure for doing that or be sent to a resource so I can learn how
this is done for quality control etc.) 

2: Is IPC the best method for this type of DATA communication between
processes? So far I think IPC would be better because its my understanding
that it happens all in memory. No disk i/o - therefore faster. Speed is
definitely the goal here.

I never used a PIPE - but I've read enough to know that PIPES might be the
way to go, and TCP IP is another. 



Best Regards,
And thanks to the Free Pascal Community for your help so far.
Jason Sage