[fpc-pascal] Inter-process communication, a cautionary tale

Mark Morgan Lloyd markMLl.fpc-pascal at telemetry.co.uk
Wed Jul 18 14:48:19 CEST 2012

I was reminded of this when somebody was asking about portable 
signalling APIs the other day, but I think it's also relevant to 
discussion of e.g. how to pass a keyword to a help viewer.

I am obviously aware of the fact that FPC has an IPC unit which uses a 
temporary file, although I have always assumed that that was more to 
support targets like DOS that had absolutely no concept of pipes or 
sockets. But perhaps it really is the safest choice in all cases.

A couple of years ago I wrote an experimental library that used a 
unix-domain socket to ensure that only a single copy of a program was 
running, and to pass a command line from any subsequent copy to the 
original. In general, it worked well; and unlike TCP etc. it was 
inherently protected from external interference.

A couple of weeks ago, out of curiosity rather than necessity, I started 
looking at whether the library could be ported to Windows using MS-style 
named pipes. However I seem to have hit a snag since it appears that 
Windows can't both create a named pipe (for reading) and open the same 
named pipe (for writing) in the same process, something that gives unix 
sockets no problems at all.

I'm not particularly looking for sympathy, and I'm not really expecting 
anybody to point out that I've overlooked something obvious (although 
suggestions would, of course, be appreciated). I'm simply outlining this 
as an illustration that the complex semantics of the Windows API can, at 
times, bite.

Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

More information about the fpc-pascal mailing list