pIPC Homepage


  • Are you using threads in your python programs regularly and you think programming messaging interfaces is a pain in the back?
  • Do you like the idea of not having to worry about anything but a singe file object for all your IPC messaging needs?
  • Interested in making your threaded sources look cleaner and more understandable for others or reuse in general?
If you can answer YES to one of these, pIPC might be of interest to you.


Basically, pIPC wraps all IPC internals into one single, easy-to-use object which can be used for read(), write() and select() calls. No more fiddling with sockets or pipes, no buffering and handling routines.

The pIPC module implements the classes Pipe and PipeEnd that can be used for hassle-free, queued inter-process communications (IPC).

Example Usage:

      import IPC
      pipe = IPC.Pipe()


      each process or thread can now (EQALLY!) use the pipe, f.e.:

      r,w,x = select([pipe],[],[],1)

      if r != []:
        if r[0] != pipe:
          raise IOError, "unknown IO in select()" # whatever... shouldnt happen
        data = pipe.read()    # This data is from the other thread, it must
                              # have called pipe.write(data)
        if len(pipe) > 0:           # If there are more messages than just one,
          moredata = pipe.pending() # you can retrieve an array of all pending
        else:                       # messages from the pipe with pending()
          pipe.write("Got no data! Are you sleeping?")  # Will be readable by
                                                        # the other thread,
                                                        # using pipe.read()
Or whatever. The pipe class will take care of everything, including queueing of multiple messages until pending messages are completely read.

If you want to do IPC with completely separate processes (i.e. spawn()ed) you will have to use named pipes aka "fifo"s. Use them almost exactly like above standard pipes, just use

      pipe = pIPC.Pipe("mypipe")   # Use your favorite unique name instead of mypipe
in both processes involved. After that you can use them in just the same way that is shown above. The fifos will be unlinked from /tmp when both sides have opened them and remain invisble.

But that is not all. If you want to do IPC between two separate computers through the net, just use

      pipe = pIPC.Pipe("remote_host_name", port [, timeout])
on both computers involved to get your pIPC message interface as usual. Whichever side is first to do so will open the port and the other side will connect to it. Optionally you can specify a how long the first link partner will wait for the second one to connect (timeout). If you need server functionality on one side, you can use
      pserv = PipeServer(port)
where port is the number of the port of the server. Put pserv into a select clause and every time it triggers just get a newly connected Pipe Object via
      pipe = pserv.accept()


  • Thoroughly tested only with linux threads (pipes) and processes (fifos)
  • version 0.9.5 and up dont work with python 1.5.2 anymore
  • Communication is strictly two-way. No "one sender and two recipients" method. Just use two Pipe()s for stuff like that.
  • Only standard Pipes are reusable. Named pipes and Network pipes will have to be disposed whenever the connection has been interrupted. (just make yourself a new pair'o'Pipe()s then, its free!)
  • The only thing that you will have to take care of is that if you end a thread and you want to re-use its end of a pipe for another process, the exiting thread will have to call pipe.disconnect() before it ends. The other end of the pipe will get a message containing the string "BYE" (plus any string you can submit as an argument as disconnect(string)). Sending any further message after disconnect() will reconnect the pipe to the calling process.
  • Messages are separated internally using the sequence "<E0X\\0>". Although it is extremely improbable that this sequence occurs in any data stream, it may cause unexpected behaviour, should this ever happen.
  • If you have lots of data sent, use select() or do pipe.flush() regularly, or messages will overflow the posix pipe buffers and cause write errors on the sending thread's side. pipe.flush() will NOT delete messages, just flush the "physical" posix pipe and store the data for later retrieval via pipe.read()
  • Always call the close() method of a pipe if you do not plan to use it any more or you might run out of file descriptors quickly.
  • pIPC is still in development. Internal structures may change in future releases, although the Pipe Class API in its current form will probably stay as it is or be expanded, but not changed. Use of other internal structures is depreciated at the moment.

Send bug reports and enhancement requests/patches to pipc@software.fionet.com If this module made your day, ask for my adress and send chocolate. ;-)


Current version:

February 14, 2013: pIPC-1.0.2.tar.gz README ToDo Changes

Older versions:

July 01, 2005: pIPC-1.0.1.tar.gz
July 24, 2003: pIPC-0.9.9.tar.gz
January 09, 2003: pIPC-0.9.8.tar.gz
January 09, 2003: pIPC-0.9.7.tar.gz
January 09, 2003: pIPC-0.9.6.tar.gz
March 06, 2002: pIPC-0.9.5.tar.gz
March 06, 2002: pIPC-0.9.2.tar.gz
November 06, 2001: pIPC-0.9.1.tar.gz