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

Jump to bottom

Fortify the thread pool against forking #1758

Closed
st-pasha opened this issue Apr 1, 2019 · 0 comments
Closed

Fortify the thread pool against forking #1758

st-pasha opened this issue Apr 1, 2019 · 0 comments
Assignees
@st-pasha
Labels
improve Improvement of an existing functionality
Projects
OMP-less parallelism
Milestone
Release 0.9.0

Comments

@st-pasha
Copy link
Contributor

st-pasha commented Apr 1, 2019 •
edited

When a process is forked (but not exec'd), the child spawns without its parent's threads; which leads to a broken thread pool: whenever any job is executed, we expect the threads to wake up and start picking the tasks -- however, if there are no threads then no tasks are ever executed and the program freezes.

We can guard against this using pthread_atfork() library function.
@st-pasha st-pasha added the improve Improvement of an existing functionality label Apr 1, 2019
@st-pasha st-pasha added this to the Release 0.9.0 milestone Apr 1, 2019
@st-pasha st-pasha self-assigned this Apr 1, 2019
@st-pasha st-pasha added this to To Do in OMP-less parallelism via automation Apr 1, 2019
@st-pasha st-pasha mentioned this issue Apr 1, 2019
Merged
OMP-less parallelism automation moved this from To Do to Done Apr 2, 2019
st-pasha added a commit that referenced this issue Apr 2, 2019
@st-pasha
Correct behavior of thread pool during forking (#1759)
ded3959 
This PR introduces two changes to the thread pool:

1. The threads are now initialized lazily, that is on the first run that they are actually required. For example function `get_thread_ids()` will always cause the threads to spawn, whereas `dt::run_parallel()` may not, if the number of rows is small enough to run single-threadedly.

2. Fixed problems with datatable hanging after the process was forked by an external module such as `multiprocessing`. Now we re-initialize the thread pool in every child process, ensuring that they do not accidentally share mutexes / condition variables / threads. 

Closes #1758 
Closes #1757
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@st-pasha st-pasha

Labels
improve Improvement of an existing functionality
Projects
No open projects
OMP-less parallelism
  
Done
Milestone
Release 0.9.0
Development

No branches or pull requests
1 participant
@st-pasha