correct let' look next at few of those tools in action ipc toolspipesshared memoryand queues while the processes created by this package can always communicate using general system-wide tools like the sockets and fifo files we met earlierthe multiprocessing module also provides portable message passing tools specifically geared to this purpose for the processes it spawnsits pipe object provides an anonymous pipewhich serves as connection between two processes when calledpipe returns two connection objects that represent the ends of the pipe pipes are bidirectional by defaultand allow arbitrary pickleable python objects to be sent and received on unix they are implemented internally today with either connected socket pair or the os pipe call we met earlierand on windows with named pipes specific to that platform much like the process object described earlierthoughthe pipe object' portable api spares callers from such things its value and array objects implement shared process/thread-safe memory for communication between processes these calls return scalar and array objects based in the ctypes module and created in shared memorywith access synchronized by default its queue object serves as fifo list of python objectswhich allows multiple producers and consumers queue is essentially pipe with extra locking mechanisms to coordinate more arbitrary accessesand inherits the pickleability constraints of pipe because these devices are safe to use across multiple processesthey can often serve to synchronize points of communication and obviate lower-level tools like locksmuch the same as the thread queues we met earlier as usuala pipe (or pair of themmay be used to implement request/reply model queues support more flexible modelsin facta gui that wishes to avoid the limitations of the gil might use the multiprocessing module' process and queue to spawn long-running tasks that post resultsrather than threads as mentionedalthough this may incur extra start-up overhead on some platformsunlike threads todaytasks coded this way can be as truly parallel as the underlying platform allows one constraint worth noting herethis package' pipes (and by proxyqueuespickle the objects passed through themso that they can be reconstructed in the receiving process (as we've seenon windows the receiver process may be fully independent python interpreterbecause of thatthey do not support unpickleable objectsas suggested earlierthis includes some callables like bound methods and lambda functions (see file multi-badq py in the book examples package for demonstration of code that violates this constraintobjects with system statesuch as socketsmay fail as well parallel system tools