Skip to content

Add quic_thread_impl.h to QUICHE platform implementation.#6174

Merged
alyssawilk merged 3 commits intoenvoyproxy:masterfrom
wu-bin:quic_platform_impl_thread
Mar 6, 2019
Merged

Add quic_thread_impl.h to QUICHE platform implementation.#6174
alyssawilk merged 3 commits intoenvoyproxy:masterfrom
wu-bin:quic_platform_impl_thread

Conversation

@wu-bin
Copy link
Copy Markdown
Contributor

@wu-bin wu-bin commented Mar 5, 2019

Description:

Add quic_thread_impl.h to QUICHE platform implementation.

QuicThreadImpl is implemented on top of Envoy::Thread. It is used by some tests and utility programs in QUICHE, but not in core QUICHE code.

Risk Level: minimal: code not used yet
Testing:

bazel test test/extensions/quic_listeners/quiche/platform:quic_platform_test --test_output=all --define quiche=enabled --experimental_remap_main_repo

bazel test test/extensions/quic_listeners/quiche/platform:quic_platform_test --test_output=all --define quiche=enabled --experimental_remap_main_repo -c opt

Docs Changes: none
Release Notes: none
[Optional Fixes #Issue]
[Optional Deprecated:]

Signed-off-by: Bin Wu <wub@google.com>
@wu-bin
Copy link
Copy Markdown
Contributor Author

wu-bin commented Mar 5, 2019

/assign @mpwarres

Copy link
Copy Markdown
Contributor

@mpwarres mpwarres left a comment

Choose a reason for hiding this comment

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

LGTM mod one nit


virtual ~QuicThreadImpl() {
if (thread_ != nullptr) {
PANIC("QuicThread should be joined before destruction.");
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

PANIC might be too severe: google3 logs at ERROR and Chromium DCHECKs for this. How about just logging at ERROR?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

There is a subtle problem, if the QuicThread is destructed immediately after Start(), but before the Run() function is called, then QuicThread::Run() becomes a call to a pure virtual function(since child has destructed), which aborts the program.

I can change QuicThread::Run() to a empty function to avoid the abort. How's that sound?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I see. On second thought, allowing the QuicThreadImpl's Run() method to execute after/while the instance has been destructed seems like inviting problems. Making QuicThread::Run() an empty function feels like skating around the issue. Let's keep the PANIC as-is.

(Another option would be to do something more complicated, like having an internal enum to differentiate between the states of "not started" vs "started but Run not invoked yet" vs "Run invoked", but that feels like overkill for behavior that we shouldn't be triggering or need, anyways. I prefer what you have currently.)

…l_thread

Signed-off-by: Bin Wu <wub@google.com>
mpwarres
mpwarres previously approved these changes Mar 6, 2019
Copy link
Copy Markdown
Contributor

@mpwarres mpwarres left a comment

Choose a reason for hiding this comment

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

LGTM, thanks!


virtual ~QuicThreadImpl() {
if (thread_ != nullptr) {
PANIC("QuicThread should be joined before destruction.");
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I see. On second thought, allowing the QuicThreadImpl's Run() method to execute after/while the instance has been destructed seems like inviting problems. Making QuicThread::Run() an empty function feels like skating around the issue. Let's keep the PANIC as-is.

(Another option would be to do something more complicated, like having an internal enum to differentiate between the states of "not started" vs "started but Run not invoked yet" vs "Run invoked", but that feels like overkill for behavior that we shouldn't be triggering or need, anyways. I prefer what you have currently.)

@alyssawilk alyssawilk merged commit f8b32a6 into envoyproxy:master Mar 6, 2019
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.

3 participants