Skip to content

feat: native plugins - #3372

Merged
ry merged 27 commits into
denoland:masterfrom
afinch7:native_plugins_2
Dec 5, 2019
Merged

ry merged 27 commits into
denoland:masterfrom
afinch7:native_plugins_2

Conversation

@afinch7

@afinch7 afinch7 commented Nov 18, 2019

Copy link
Copy Markdown
Contributor

Now that we are using futures 0.3 I should be able to finish this.

Api will look a little different this time to reflect some of the refactors that have occurred since #2385.

I'm targeting something like this on the plugin side:

use deno::CoreOp;
use deno::Op;
use deno::{Buf, PinnedBuf};
use deno::PluginInitContext;
use futures::future::FutureExt;

#[macro_use]
extern crate deno;

fn init(context: &mut dyn PluginInitContext) {
  context.register_op("some_op", Box::new(some_op));
}
init_fn!(init);

pub fn some_op(data: &[u8], zero_copy: Option<PinnedBuf>) -> CoreOp {
  if let Some(buf) = zero_copy {
    let data_str = std::str::from_utf8(&data[..]).unwrap();
    let buf_str = std::str::from_utf8(&buf[..]).unwrap();
    println!(
      "Hello from native bindings. data: {} | zero_copy: {}",
      data_str, buf_str
    );
  }
  let result = b"test";
  Op::Sync(result.into())
}

and something like this on the typescript side:

const plugin = Deno.openPlugin("./path/to/some/lib.so");
const some_op = plugin.ops.some_op;

function doSomeOp(): null | ArrayBufferView {
  const response = some_op.dispatch(new UInt8Array([1,2,3,4]));
  return response;
}

refs #3366 #2473

@afinch7
afinch7 force-pushed the native_plugins_2 branch 2 times, most recently from fef9c0c to 661e5a4 Compare November 18, 2019 17:56

@bartlomieju bartlomieju left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

There are a few things I have questions about, but I believe this might be very solid MVP for native plugins;
a) it's built on ops
b) this is the simplest iteration, doesn't expose state to op dispatcher in Rust, we can iterate on API safely

Comment thread cli/ops/native_plugins.rs Outdated
Comment thread cli/ops/native_plugins.rs Outdated
Comment thread cli/ops/native_plugins.rs Outdated

@ry ry left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I like that this is only +400 lines

@afinch7
afinch7 force-pushed the native_plugins_2 branch 2 times, most recently from 7df0cbd to 1fc95be Compare November 19, 2019 22:12
@afinch7
afinch7 marked this pull request as ready for review November 19, 2019 23:32
@afinch7

afinch7 commented Nov 20, 2019

Copy link
Copy Markdown
Contributor Author

For some reason workers_startup_bench.ts doesn't terminate now. I don't think that I changed anything that would break that.

Comment thread cli/worker.rs Outdated
@afinch7 afinch7 changed the title [WIP] feat: native plugins feat: native plugins Nov 22, 2019

@bartlomieju bartlomieju left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

It is very solid PR, especially because all changes introduced in it are minimal - it allows to iterate on the API before 1.0 release. It's well aligned with our ops APIs and has minimal impact on current architecture 👍 I'd love to see this landed to give users chance to use it and break it 🚀

Comment thread .github/workflows/ci.yml Outdated
- name: Test debug
if: matrix.kind == 'test_debug'
run: |
cargo build --locked -p test_native_plugin

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Can this step be somehow integrated into cli/tests/integration_tests.rs flow?

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.

I tried to add a single test to test_native_plugin, but it still doesn't build automatically when running cargo test --all-targets. Not sure if there may be some other simple workaround here.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

We should figure out a way to test this without making changes to ci.yml... I'm looking into it.

Comment thread cli/flags.rs Outdated
Comment thread cli/js/dispatch.ts
Comment thread cli/js/native_plugins.ts
Comment thread cli/ops/native_plugins.rs Outdated
Comment thread cli/permissions.rs Outdated
Comment thread cli/tests/test_native_plugin/src/lib.rs
* Rename `allow_native`/`allow-native` to `allow_plugin`/`allow-plugin`. This makes more sense with the primary public api function being `openPlugin`.
* Fully intagrate the newly added permission type `plugin`.
* Add docs to `Deno.openPlugin`.
* Generate op names for native plugin ops that avoid potential collision.

Lastly this commit adds a delayed future to native plugins async test op. This should properly test the function of contexts/tasks/wakers in async native plugin ops. This would not function correctly with futures 0.1, and thus was a major blocker. This test proves this issue no longer exists in this implementation. The most analogous problem I can think of here is loading two copies of the same TS lib: the share the same type thus are interoperable, but don't share the same module local data(closest comparison to TLS used to store current task in futures). This isn't a problem anymore, since futures now pass `Context` values directly during calls to `poll` with the new API.
Comment thread cli/tests/test_native_plugin/src/lib.rs
@ry

ry commented Nov 27, 2019

Copy link
Copy Markdown
Member

I've merged this branch with master and moved a few things around. I think the plugin infrastructure shouldn't depend on cli, so the tests shouldn't be in cli. I'll try to do that now...

@ry

ry commented Nov 28, 2019

Copy link
Copy Markdown
Member

So.. I'm still having the same trouble you were having, @afinch7, with getting the plugin to build for the test. I guess moving the test_plugin crate to the root didn't help. I've done some superficial clean ups. I'm pretty much ready to land this if we can get it to go green somehow.

fn basic() {
let mut build_plugin_base = Command::new("cargo");
let mut build_plugin =
build_plugin_base.arg("build").arg("-p").arg("test_plugin");

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

It's annoying that it's not built already when the integration tests run. I wish I knew some cargo expert who could advise us here.

@ry ry left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

LGTM - Thank you for the long and hard work of getting this in @afinch7 !

@ry
ry merged commit 7c3b9b4 into denoland:master Dec 5, 2019
@ry ry mentioned this pull request Dec 6, 2019
40 of 43 tasks
bartlomieju pushed a commit to bartlomieju/deno that referenced this pull request Dec 28, 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