-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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
worker: make MessagePort uv_async_t
inline field
#26271
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -469,18 +469,18 @@ MessagePort::MessagePort(Environment* env, | |
Local<Object> wrap) | ||
: HandleWrap(env, | ||
wrap, | ||
reinterpret_cast<uv_handle_t*>(new uv_async_t()), | ||
reinterpret_cast<uv_handle_t*>(&async_), | ||
AsyncWrap::PROVIDER_MESSAGEPORT), | ||
data_(new MessagePortData(this)) { | ||
auto onmessage = [](uv_async_t* handle) { | ||
// Called when data has been put into the queue. | ||
MessagePort* channel = static_cast<MessagePort*>(handle->data); | ||
MessagePort* channel = ContainerOf(&MessagePort::async_, handle); | ||
channel->OnMessage(); | ||
}; | ||
CHECK_EQ(uv_async_init(env->event_loop(), | ||
async(), | ||
&async_, | ||
onmessage), 0); | ||
async()->data = static_cast<void*>(this); | ||
async_.data = static_cast<void*>(this); | ||
|
||
Local<Value> fn; | ||
if (!wrap->Get(context, env->oninit_symbol()).ToLocal(&fn)) | ||
|
@@ -494,21 +494,13 @@ MessagePort::MessagePort(Environment* env, | |
Debug(this, "Created message port"); | ||
} | ||
|
||
void MessagePort::AddToIncomingQueue(Message&& message) { | ||
data_->AddToIncomingQueue(std::move(message)); | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. how is this change related? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It’s not, it’s just something that I noticed, and putting it into another PR would have lead to yet another merge conflict. I’ve split it into a separate commit, as @bnoordhuis suggested. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. thanks. part of my question (which I meant to ask but did not come out like that) was why this change required at all - that is not covered in the PR description. But I got it now as: it is an unused piece of code. |
||
|
||
uv_async_t* MessagePort::async() { | ||
return reinterpret_cast<uv_async_t*>(GetHandle()); | ||
} | ||
|
||
bool MessagePort::IsDetached() const { | ||
return data_ == nullptr || IsHandleClosing(); | ||
} | ||
|
||
void MessagePort::TriggerAsync() { | ||
if (IsHandleClosing()) return; | ||
CHECK_EQ(uv_async_send(async()), 0); | ||
CHECK_EQ(uv_async_send(&async_), 0); | ||
} | ||
|
||
void MessagePort::Close(v8::Local<v8::Value> close_callback) { | ||
|
@@ -643,7 +635,6 @@ void MessagePort::OnClose() { | |
data_->Disentangle(); | ||
} | ||
data_.reset(); | ||
delete async(); | ||
} | ||
|
||
std::unique_ptr<MessagePortData> MessagePort::Detach() { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to ask this earlier as well - what is the consideration behind obtaining
this
through pointer arithmetic over the other one?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For one, the address can't change; the contents of
handle->data
can.In fact, the old code is mildly wrong because HandleWrap also sets
handle_->data = this
(wherethis
is an instance of HandleWrap rather than MessagePort) so static_casting that to MessagePort afterwards would be wrong if multiple inheritance were involved.