没有STDOUT的两个python脚本之间的进程间通信

Question

I am trying to create a Monitor script that monitors all the threads or a huge python script which has several loggers running, several thread running.

From Monitor.py i could run subprocess and forward the STDOUT which might contain my status of the threads.. but since several loggers are running i am seeing other logging in that..

Question: How can run the main script as a separate process and get custom messages, thread status without interfering with logging. ( passing PIPE as argument ? )

Main_Script.py * Runs Several Threads * Each Thread has separate Loggers.

Monitor.py * Spins up the Main_script.py * Monitors the each of the threads in MainScript.py ( may be obtain other messages from Main_script in the future)

So Far, I tried subprocess, process from Multiprocessing.

Subprocess lets me start the Main_script and forward the stdout back to monitor but I see the logging of threads coming in through the same STDOUT. I am using the “import logging “ Library to log the data from each threads to separate files.

I tried “process” from Multiprocessing. I had to call the main function of the main_script.py as a process and send a PIPE argument to it from monitor.py. Now I can't see the Main_script.py as a separate process when I run top command.

Answer 1

Normally, you want to change the child process to work like a typical Unix userland tool: the logging and other side-band information goes to stderr (or to a file, or syslog, etc.), and only the actual output goes to stdout.

Then, the problem is easy: just capture stdout to a PIPE that you process, and either capture stderr to a different PIPE , or pass it through to real stderr .

---

If that's not appropriate for some reason, you need to come up with some other mechanism for IPC: Unix or Windows named pipes, anonymous pipes that you pass by leaking the file descriptor across the fork / exec and then pass the fd as an argument, Unix-domain sockets, TCP or UDP localhost sockets, a higher-level protocol like a web service on top of TCP sockets, mmap ped files, anonymous mmap s or pipes that you pass between processes via a Unix-domain socket or Windows API calls, …

As you can see, there are a huge number of options. Without knowing anything about your problem other than that you want "custom messages", it's impossible to tell you which one you want.

While we're at it: If you can rewrite your code around multiprocessing rather than subprocess , there are nice high-level abstractions built in to that module. For example, you can use a Queue that automatically manages synchronization and blocking, and also manages pickling/unpickling so you can just pass any (picklable) object rather than having to worry about serializing to text and parsing the text. Or you can create shared memory holding arrays of int32 objects, or NumPy arrays, or arbitrary structures that you define with ctypes . And so on. Of course you could build the same abstractions yourself, without needing to use multiprocessing , but it's a lot easier when they're there out of the box.

---

Finally, while your question is tagged ipc and pipe , and titled "Interprocess Communication", your description refers to threads , not processes. If you actually are using a bunch of threads in a single process, you don't need any of this.

You can just stick your results on a queue.Queue , or store them in a list or deque with a Lock around it, or pass in a callback to be called with each new result, or use a higher-level abstraction like concurrent.futures.ThreadPoolExecutor and return a Future object or an iterator of Future s, etc.