Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change processor to prevent errors in python>=3.7 #236

Merged
merged 3 commits into from Mar 2, 2020

Conversation

JoranAngevaare
Copy link
Member

While processing data with bootstrax I noticed errors while processing data with python3.7 or python3.8. Changing this option solves the errors.

The error message is added below for convenience (in python 3.7):
Traceback (most recent call last):

File "/home/xedaq/miniconda/envs/py37/lib/python3.7/threading.py", line 926, in _bootstrap_inner
	self.run()
File "/home/xedaq/miniconda/envs/py37/lib/python3.7/threading.py", line 870, in run
	self._target(*self._args, **self._kwargs)
File "/home/xedaq/miniconda/envs/py37/lib/python3.7/concurrent/futures/process.py", line 375, in _queue_management_worker
	thread_wakeup.clear()
File "/home/xedaq/miniconda/envs/py37/lib/python3.7/concurrent/futures/process.py", line 93, in clear
	while self._reader.poll():
File "/home/xedaq/miniconda/envs/py37/lib/python3.7/multiprocessing/connection.py", line 255, in poll
	self._check_closed()
File "/home/xedaq/miniconda/envs/py37/lib/python3.7/multiprocessing/connection.py", line 136, in _check_closed
	raise OSError("handle is closed")
OSError: handle is closed

or in python 3.8:

Traceback (most recent call last):
File "/home/xedaq/miniconda/envs/py38/lib/python3.8/threading.py", line 932, in _bootstrap_inner
    self.run()
File "/home/xedaq/miniconda/envs/py38/lib/python3.8/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
File "/home/xedaq/miniconda/envs/py38/lib/python3.8/concurrent/futures/process.py", line 376, in _queue_management_worker
    thread_wakeup.clear()
File "/home/xedaq/miniconda/envs/py38/lib/python3.8/concurrent/futures/process.py", line 94, in clear
    self._reader.recv_bytes()
File "/home/xedaq/miniconda/envs/py38/lib/python3.8/multiprocessing/connection.py", line 216, in recv_bytes
    buf = self._recv_bytes(maxlength)
File "/home/xedaq/miniconda/envs/py38/lib/python3.8/multiprocessing/connection.py", line 414, in _recv_bytes
    buf = self._recv(4)
File "/home/xedaq/miniconda/envs/py38/lib/python3.8/multiprocessing/connection.py", line 379, in _recv
 77602 MainThread ThreadedMailboxProcessor Waiting for subprocesses to end
    chunk = read(handle, remaining)
OSError: [Errno 9] Bad file descriptor

While processing data with bootstrax I noticed errors while processing data with python3.7 or python3.8. Changing this option solves the errors.

The error message is added below for convenience (in python 3.7):
Traceback (most recent call last):
  File "/home/xedaq/miniconda/envs/py37/lib/python3.7/threading.py", line 926, in _bootstrap_inner
    self.run()
  File "/home/xedaq/miniconda/envs/py37/lib/python3.7/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "/home/xedaq/miniconda/envs/py37/lib/python3.7/concurrent/futures/process.py", line 375, in _queue_management_worker
    thread_wakeup.clear()
  File "/home/xedaq/miniconda/envs/py37/lib/python3.7/concurrent/futures/process.py", line 93, in clear
    while self._reader.poll():
  File "/home/xedaq/miniconda/envs/py37/lib/python3.7/multiprocessing/connection.py", line 255, in poll
    self._check_closed()
  File "/home/xedaq/miniconda/envs/py37/lib/python3.7/multiprocessing/connection.py", line 136, in _check_closed
    raise OSError("handle is closed")
OSError: handle is closed

or in python 3.8:
	Traceback (most recent call last):
	  File "/home/xedaq/miniconda/envs/py38/lib/python3.8/threading.py", line 932, in _bootstrap_inner
	    self.run()
	  File "/home/xedaq/miniconda/envs/py38/lib/python3.8/threading.py", line 870, in run
	    self._target(*self._args, **self._kwargs)
	  File "/home/xedaq/miniconda/envs/py38/lib/python3.8/concurrent/futures/process.py", line 376, in _queue_management_worker
	    thread_wakeup.clear()
	  File "/home/xedaq/miniconda/envs/py38/lib/python3.8/concurrent/futures/process.py", line 94, in clear
	    self._reader.recv_bytes()
	  File "/home/xedaq/miniconda/envs/py38/lib/python3.8/multiprocessing/connection.py", line 216, in recv_bytes
	    buf = self._recv_bytes(maxlength)
	  File "/home/xedaq/miniconda/envs/py38/lib/python3.8/multiprocessing/connection.py", line 414, in _recv_bytes
	    buf = self._recv(4)
	  File "/home/xedaq/miniconda/envs/py38/lib/python3.8/multiprocessing/connection.py", line 379, in _recv
	 77602 MainThread ThreadedMailboxProcessor Waiting for subprocesses to end
	    chunk = read(handle, remaining)
	OSError: [Errno 9] Bad file descriptor
@JelleAalbers
Copy link
Member

Hi Joran, that's interesting, since Travis does run on python 3.7... If you enable wait=True in ProcessPoolExecutor.shutdown there is no timeout, so we instead sleep for up to 20 seconds after calling shutdown(wait=False). However, the sleep ends early or never activates if all child processes are already dead. Maybe there is some further cleanup that has to happen even then. Perhaps it's sufficient to sleep a few extra seconds after we determined all the child processes are dead?

@JoranAngevaare
Copy link
Member Author

It also looks more like a warning than an error that triggers a crash. Hence it could very well be that travis does not fail because of this.

I've not been able to mitigate this error with adding additional sleep statements.

This could potentially infinite hangs on bad crashes, but should be better for normal processing
Copy link
Member

@JelleAalbers JelleAalbers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, thanks for checking.

With this change we don't need the brute-force-killing code anymore (in the bad-crash situation it was meant for, we will anyway hang infinitely), and we might as well wait on the ThreadPoolExecutor too. Even if we do get a hang, it shouldn't be too bad, since bootstrax will eventually kill a hanging strax process.

@JelleAalbers JelleAalbers merged commit 007b0bc into AxFoundation:master Mar 2, 2020
@JoranAngevaare JoranAngevaare deleted the patch-2 branch March 12, 2020 16:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants