Skip to content

Sync threads on startup #1242

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

Merged
merged 4 commits into from
Mar 30, 2017
Merged

Sync threads on startup #1242

merged 4 commits into from
Mar 30, 2017

Conversation

deweerdt
Copy link
Member

It's possible that not all threads have started by the time other
threads start to serve requests.

This is in particular problematic with the status handler: the
on_req_json function relies on on_context_init being called for all
threads, but in fact the call of h2o_multithread_register_receiver
might be racing against the value of self->receivers.size.

This results in more threads being called than
collector->num_remaining_threads_atomic. A consequence of this can be
that either send_response is not called (and the fd of the request
is leaked), or on final() being called twice (leading to a possible
double free).

This commit solves the issue by introducing a barrier-like API that we use
as a synchronization point at startup time. By doing this, it's not possible
anymore that threads serve requests without all of them being initialized.

It's possible that not all threads have started by the time other
threads start to serve requests.

This is in particular problematic with the status handler: the
`on_req_json` function relies on `on_context_init` being called for all
threads, but in fact the call of `h2o_multithread_register_receiver`
might be racing against the value of `self->receivers.size`.

This results in more threads being called than
`collector->num_remaining_threads_atomic`. A consequence of this can be
that either `send_response` is not called (and the fd of the request
is leaked), or on `final()` being called twice (leading to a possible
double free).

This commit solves the issue by introducing a synchronization point
in the initialization, in order to make sure that all contexts for all
threads are initialized before starting to serve requests.
We the use this to synchronize the initialization of the threads run in
src/main.c, so that we don't start servicing requests before the
initialization has been complete.
@kazuho kazuho added this to the v2.2 milestone Mar 30, 2017
@kazuho kazuho merged commit be16e94 into h2o:master Mar 30, 2017
@kazuho
Copy link
Member

kazuho commented Mar 30, 2017

Thank you for the fix and the new building block (for writing barriers).

@deweerdt deweerdt deleted the sync-threads-on-startup branch March 30, 2017 18:26
@kazuho kazuho mentioned this pull request Apr 11, 2017
2 tasks
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.

2 participants