Skip to content
This repository has been archived by the owner on Aug 17, 2022. It is now read-only.

Correspondence between adapter and import/export funcs #119

Open
mikevoronov opened this issue Jun 24, 2020 · 6 comments
Open

Correspondence between adapter and import/export funcs #119

mikevoronov opened this issue Jun 24, 2020 · 6 comments

Comments

@mikevoronov
Copy link

mikevoronov commented Jun 24, 2020

What is a way of correspondence indication between adapter and core funcs? I can't find this in the docs in this repo. As far as I know, it is done by the implementation subsection that contain correspondence between types of adapter and core func types like here.

If it is true, lets imagine the situation where we have several functions with the same type: (@interface type (func (param string) (result string))). All adapter for these functions will be similar except arg of call-core instructions. So to differentiate we need several ephemeral types for adapters and core functions (like in the example here - the only difference call-core 6 and call-core 7 and they have to have unique type for all adapter because of this way of organizing of the implementation section).

@fgmccabe
Copy link
Contributor

Your assumption is not correct.
There are some details still to be worked out; however, the main point is that the interface types' 'version' of a function is conceptually separate from any particular core wasm function.
Something like this: if core func CA in module A wants to access core func CB in module B then a 'chain' of functions is set up:

CA -> ACA -> ACB -> CB

where ACA and ACB are the import adapter and export adapters respectively. The 'bridge' between ACA and ABC looks like a regular function call - except that the function signatures are expressed as Interface Types.

CA knows how to call ACA because module A imports a function and the 'wrapper' module supplies ACA as the implementation of the import. ACA knows to call ACB because the host embedder (or other entity) has designated module AB (adapted module B) as the way of satsifying the import by ACA. ACB knows to call CB because AB wraps module B and effectively imports module B: i.e., function CB satisfies the import(s) that AB makes.

This whole story is actually (going to be) part of the module linking story where modules can be composed in useful ways.

Does this clarify?

@mikevoronov
Copy link
Author

mikevoronov commented Jun 25, 2020

Sorry, my question was unclear.

the 'wrapper' module supplies ACA as the implementation of the import.
ACB knows to call CB because AB wraps module B

My question is related exactly to this correspondence. How to exactly point out that this adapter implements (wraps) this core function?

I can't find this info in the docs of this repo, Wasmer uses scheme with implementations - a separate table with correspondence between core function type and adapter type (example is here). And there is an unclear moment with this scheme that I described in the first message.

@fgmccabe
Copy link
Contributor

In all cases, it uses existing mechanisms, specifically, invoking an imported function. There is no separate mechanism for calling adapter functions.
Please do not rely on any currently experimental implementations.

@mikevoronov
Copy link
Author

mikevoronov commented Jun 25, 2020

It seems that you mean that implementation table isn't really needed and adapter shoud be able to call as a "usual" import and export function. It is clear for me how to call adapter as a module export function and how to make this on the side of a Wasm execution environment. And what about transition beetwen CA -> ACA in the CA -> ACA -> ACB -> CB sheme? How a Wasm execution environment should obtain correspondence between "import adapter" ACA and export function from external module CB?

@fgmccabe
Copy link
Contributor

An import adapter function has a core wasm signature. Its role is to act as the importee: i.e., when a core wasm module imports a function, the import adapter counts as satisfying the import. For normal imports, this is handled by (a) providing an implementation for the imported function and (b) letting the host connect your implementation as the import for the module.
In the case of adapters, the implementation is actually provided as part of the wrapper module. Of course, there is another import -- of the interface types function ...

@mikevoronov
Copy link
Author

mikevoronov commented Jun 25, 2020

Thank you, got it. I think, It would be really good to describe this somewhere in the docs.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants