multiprocessing.Process.start hangs when a Thread is waiting for input()

[jonas-wago]

Bug report

Bug description:

Actual behavior
Having a Thread running which is waiting for a user cli input lets a newely started multiprocessing Process hang until the user provides the cli input for the Thread once.

The target method of the Process will not get called until the input is provided.
After the user has provided the input for the thread, the target of the Process beginns executing.
Regardless if the Thread is now waiting for further user input, the target of the Process continues running.

Expected behavior
I would expect the target of the Process to begin executing directly when start gets called, regardless of any Thread waiting for user input.

Minimal example

from threading import Thread
from multiprocessing import Process
import time

def thread_worker():
    while True:
        input()
        print(f"Thread: {time.time_ns()}")
        time.sleep(1)

def process_worker():
    while True:
        print(f"Process: {time.time_ns()}")
        time.sleep(1)

def main():
    t = Thread(target=thread_worker)
    t.start()
    p = Process(target=process_worker)
    p.start()
    while True:
        print(f"Parent: {time.time_ns()}")
        time.sleep(1)

if __name__ == '__main__':
    main()

Parent: 1744127459390331500
Parent: 1744127460391104200
Parent: 1744127461391702600
Parent: 1744127462391891200
Parent: 1744127463391976800
<-- User pressed <Enter> here
Thread: 1744127463907895600
Process: 1744127464027620700
Parent: 1744127464392826400
Process: 1744127465027796400
Parent: 1744127465393627600
Process: 1744127466028309500
Parent: 1744127466394346500
Process: 1744127467028522100
Parent: 1744127467395162900
<-- User pressed <Enter> here
Thread: 1744127468003765700
Process: 1744127468029055500
Parent: 1744127468395581600
Process: 1744127469029577600
Parent: 1744127469395885500
Process: 1744127470030224200
Parent: 1744127470396392600
Process: 1744127471030760100
Parent: 1744127471396828100

I find it unexpected that before the first <-- User pressed <Enter> here there is no output of the Process.

CPython versions tested on:

3.12

Operating systems tested on:

Windows

[YvesDup]

Actual behavior
Having a Thread running which is waiting for a user cli input lets a newely started multiprocessing Process hang until the user provides the cli input for the Thread once.

You have to synchronize your process and thread with an synchronize primitive as a multiprocessing.Event for instance.

The target method of the Process will not get called until the input is provided.
After the user has provided the input for the thread, the target of the Process beginns executing.

Perhars you can create your process in the main, and start this process the thread just after the first input is complete ?

Expected behavior
I would expect the target of the Process to begin executing directly when start gets called, regardless of any Thread waiting for user input.

The process starts as soon as possible but it is really slower than a start of thread.

IMO It a design issue.

[jonas-wago]

You have to synchronize your process and thread with an synchronize primitive as a multiprocessing.Event for instance.
Perhars you can create your process in the main, and start this process the thread just after the first input is complete ?

When I start the process before starting the thread and start the thread only afterwards (while the process target methode is already running), then everything is printed as I expect it. So some kind of synchronization (that ensures that no thread is waiting for input during startup of a process) is indeed a workaround for this issue:

    p = Process(target=process_worker)
    p.start()
    time.sleep(1)
    t = Thread(target=thread_worker)
    t.start()

I used the time.sleep(1) as a very primitive, dangerous synchronization, otherwise the process start still hangs. I think this is because the thread starts quicker than the process start. So the thread has already started and is waiting for input when the process is still starting.

The process starts as soon as possible but it is really slower than a start of thread.
IMO It a design issue.

I do expect the process to take some time to start. But I waited for 5s in the example without its target methode beginning executing and printing stuff. So I think some kind of locking is happening which is preventing the process to start.
IMO a process should always start, no matter what some other thread does. So IMO this is a bug.

[YvesDup]

On MacOSX and Python 3.12 I have got the expected behavior. And with your reply, I figure out what is your problem. Maybe it's cause you are on Windows. I am sorry, you are right, it is not a design problem.

In multiprocessing/process.py there is a private _bootstrap method that is called where starting a new process.

cpython/Lib/multiprocessing/process.py

Lines 290 to 300 in 3feac7a

	def _bootstrap(self, parent_sentinel=None):
	from . import util, context
	global _current_process, _parent_process, _process_counter, _children
	try:
	if self._start_method is not None:
	context._force_start_method(self._start_method)
	_process_counter = itertools.count(1)
	_children = set()
	util._close_stdin()
	old_process = _current_process

In line 299, there is a call to util._close_stdin().
I am wondering if your script still hangs when you comment this line ?

[jonas-wago]

Yes, I am using windows.
Thanks for the suggestions. Sadly commenting util._close_stdin() does not do the trick.

However I figured out something else: In normal windows cmd, executing the python script (with or without commenting) works like I expect it would (Parent & Process prints).
Only when executing the script in PyCharm this issue occurs. So this might no be a problem of Python after all but rather of the PyCharm execution enviroment? I have created PY-51922 for investigation in PyCharm.