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

Minimal Worker support #1476

Merged
merged 2 commits into from
Jan 8, 2019
Merged

Minimal Worker support #1476

merged 2 commits into from
Jan 8, 2019

Conversation

ry
Copy link
Member

@ry ry commented Jan 7, 2019

This adds the ability to spawn additional Isolates from Rust and send
and receive messages from them. This is preliminary work to support
running the typescript compiler in a separate isolate and thus support
native ES modules (#975).

This is a prerequisite commit to #1460

@ry ry mentioned this pull request Jan 7, 2019
This adds the ability to spawn additional Isolates from Rust and send
and receive messages from them. This is preliminary work to support
running the typescript compiler in a separate isolate and thus support
native ES modules (denoland#975).
src/resources.rs Outdated Show resolved Hide resolved
@ry ry requested a review from piscisaureus January 8, 2019 00:36
Box::new(futures::future::err(err))
}

// https://github.com/denoland/deno/blob/golang/os.go#L100-L154
fn op_code_fetch(
state: &IsolateState,
state: &Arc<IsolateState>,
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if we should refactor so that IsolateState itself has Send, instead of wrapping in an Arc everywhere. After all the Mutex is already internalized...

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure. These types of refactors are generally easy to do due to the type system. I'd leave this as is for now because of laziness...

}
}

fn op_worker_get_message(
Copy link
Member

Choose a reason for hiding this comment

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

Seeing this does make me feel a bit stronger in favor of a unified messaging substrate instead of having distinct ones.

Copy link
Member Author

@ry ry Jan 8, 2019

Choose a reason for hiding this comment

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

We do have a unified messaging substrate; getMessage and postMessage are built on top of the lower-level op dispatch system.

I'd rephrase your suggestion: "postMessage should be the means that we dispatch ops."

I'm not so convinced of that. I think we have very particular concerns in the IPC system that the WebWorkers API doesn't address like synchronous responses, zero-copy buffers.


/// Rust interface for WebWorkers.
pub struct Worker {
isolate: Isolate,
Copy link
Member

Choose a reason for hiding this comment

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

Is Isolate itself just a wrapper around a pointer, or a class with lots of data members?
Asking because if the latter is the case, this inflates every entry in the resource table to something potentially huge.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, it's a class with data members - it's not just a pointer. Your comment is valid.

I agree that the resource table should have Box elements instead of directly containing structs - but I'd rather do that refactor in a different PR.

pub fn add_worker(wc: WorkerChannels) -> Resource {
let rid = new_rid();
let mut tg = RESOURCE_TABLE.lock().unwrap();
let r = tg.insert(rid, Repr::Worker(wc));
Copy link
Member

Choose a reason for hiding this comment

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

Same question as we had once with HTTP -- where does the worker get removed from the resource table?

Copy link
Member Author

Choose a reason for hiding this comment

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

They weren't being correctly removed. I've fixed this now. When the thread exits it calls resource.close() which removes it from the table. I've added a test to ensure this.

Copy link
Member

@piscisaureus piscisaureus left a comment

Choose a reason for hiding this comment

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

Nice work! Surely this wasn't easy to pull off...
See comments (not much). Most important: the worker resource get released?

Copy link
Contributor

@dsseng dsseng left a comment

Choose a reason for hiding this comment

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

🎉 Hooray! Workers!

@ry ry merged commit 6f79ad7 into denoland:master Jan 8, 2019
@ry ry deleted the workers branch January 8, 2019 19:44
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