Inventory of IPC methods explores the avenues for transporting information between processes. See message passing for higher-level systems.
Inter-process communication is the foundation upon which features and systems such as RPC, distributed computation, program execution, and remote execution are built.
The selection and clipboard are technically also IPC mechanisms, at least on X platforms.
DDE and COM are Windows only. Also, sh8 is Windows only.
The most common forms of IPC in Tcl work through a channel. They differ quite a lot in how that channel is created, and sometimes also in what properties it may have, but once it's established one uses the same kind of read, gets, puts, fconfigure, fileevent, etc. commands for all of them.
Quite a few extensions have been written for shared-memory IPC.
semaphores: http://www.equi4.com/pub/pp/sorted/net/svipc-2.2.0/Index.html (or perhaps ftp://ftp.tcl.tk/pub/tcl/mirror/ftp.procplace.com/alcatel/extensions/svipc-2.1.1.tar.gz ) which covers semaphores, shared memory, and message queues. lexfiend 2007-12-30: It's definitely not building with modern Tcl's & *nixes, but I'm working on a patch for that. More when it's done.
[List probably incomplete. Other systems may also provide high-level interfaces comparable to those of these packages.]
A process declares a set of "services" that other processes may call or send messages to. Could also be viewed as object-oriented IPC: a process exposes one or several objects, letting other processes send them messages. Service-oriented interfaces tend to be closer to the user than remote procedure call interfaces (e.g. only doing things for which there is also a UI), but there is no clear boundary.
The packages listed under "Application-level message passing" above usually provide this kind of interface.
apptalk builds on Tk's send, and provides for starting the target process if is isn't already running.
TooCL is a Tooltalk interface to Tcl/Tk.
TV: Bear in mind, for those who don't already, that there are a few basic mechanisms on the os-es and machines I'm aware of, of which signals, sockets (of the local and inet kind), and shared memory are the main ones. Most of the others, including many packages, don't add anything at all or much to the fundamental capacities of these mechanisms in essence, so many limitations and shortcomings of a lot of the parallel programming aids or simulations simply run into the problems and limitations of these facilities, which are on unix, linux, windows, and probably (though there I didn't program them myself), and probably on some of the less well known os-es, too.
To begin with, there is hardly formatting involved in the basics, except essential flow control, there is always overhead for copying data around except in few extreme cases, already in the basic library use, there is no or not much support for actual parallel machine concepts, except that ethernet and maybe some others can be made to broadcast over standard enough socket interface, and generally there is bad or absent exact definition of the operation of the basic library functions, for instance with the important aspect of flow control. Which is the direct and only reason a lot of things fuck up or don't work right over various versions, brands and programmers on the Internet. In Java for instance. In many printer spoolers, for instance.
Not to mention what this does to performance, a concept a modern university informaticist couldn't even spell out let alone specify, measure right and interpret with some engineering sense to begin with, let alone be able to incorporate in a design, let along in an important language definition.
A lot of interfaces and languages serve no purpose one can optimize much or say something positively discriminating about because its just a style someone likes, or something their mothers don't recognize, or maybe a certain concept applied consistently.
Some things in tcl, such as the copying of data over sockets are quite optimizable and well designed and for a scripting language highly optimal in certain sense.
2003-10-14: I did pcom years ago, which can be used for for instance remote command execution, see examples down the page, and remote execution using tcl and Pcom.
TV 2007-01-07: In Tcl on Cuda there is another mechanism at stake: interprocessing communication between the Parallel Processing Elements via shared registers or (fast) memory, and PCI-express-based passing of data (through pointers and mallocs on both sides) with CopyCputoGpu and CopyGputoCpu functions. Advantages: very high speed, in my case 1000 Megabytes/sec measured also with low latency!
When the OpenGL processor is considered as taking part in inter-process communication, like when it receives data from the cpu or even from the Cuda processors/thread engines (for recent mainstream NVidia cards), see for instance the gaussianblur example from the sdk. This can be linked with Tcl, and via tcl3d for instance (se e.g. bwise 3D graphics viewer block) with Tk.
Lars H: That sounds more like inter-processor-communication than inter-process-communication.
TV: Right. The processors all run at least one process (or a kernel and a process) and the host runs processes, the openGL is probably viewable as a process per pipeline and a global processor, and shader processes. What a grammar!
Lars H: Linguistic contortions aside, it's still not inter-process communication (but rather some form of threads), and therefore not relevant on this page.
TV: Sorry lad, the thing on the host is a process, period. Apparently you aren't aware of what I'm doing but I intend to port things in Tcl to cuda, which runs processes on threads on processors. If you find that linguistically a problem, fine.