about why you may (or may notcare about this package in more specific termsalthough this module' performance may not compete with that of pure threads or process forks for some applicationsthis module offers compelling solution for manycompared to raw process forksyou gain cross-platform portability and powerful ipc tools compared to threadsyou essentially trade some potential and platformdependent extra task start-up time for the ability to run tasks in truly parallel fashion on multi-core or multi-cpu machines on the other handthis module imposes some constraints and tradeoffs that threads do notsince objects are copied across process boundariesshared mutable state does not work as it does for threads--changes in one process are not generally noticed in the other reallyfreely shared state may be the most compelling reason to use threadsits absence in this module may prove limiting in some threading contexts because this module requires pickleability for both its processes on windowsas well as some of its ipc tools in generalsome coding paradigms are difficult or nonportable--especially if they use bound methods or pass unpickleable objects such as sockets to spawned processes for instancecommon coding patterns with lambda that work for the threading module cannot be used as process target callables in this module on windowsbecause they cannot be pickled similarlybecause bound object methods are also not pickleablea threaded program may require more indirect design if it either runs bound methods in its threads or implements thread exit actions by posting arbitrary callables (possibly including bound methodson shared queues the in-process model of threads supports such direct lambda and bound method usebut the separate processes of multiprocessing do not in fact we'll write thread manager for guis in that relies on queueing in-process callables this way to implement thread exit actions--the callables are queued by worker threadsand fetched and dispatched by the main thread because the threaded pymailgui program we'll code in both uses this manager to queue bound methods for thread exit actions and runs bound methods as the main action of thread itselfit could not be directly translated to the separate process model implied by multiprocessing without getting into too many details hereto use multiprocessingpymailgui' actions might have to be coded as simple functions or complete process subclasses for pickleability worsethey may have to be implemented as simpler action identifiers dispatched in the main processif they update either the gui itself or object state in general --pickling results in an object copy in the receiving processnot reference to the originaland forks on unix essentially copy an entire process updating the state parallel system tools