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

Host reject to freeze? #20

Closed
Jack-Works opened this issue Dec 24, 2024 · 5 comments
Closed

Host reject to freeze? #20

Jack-Works opened this issue Dec 24, 2024 · 5 comments

Comments

@Jack-Works
Copy link
Member

It might be possible there is a host API like this:

const process = new Process('./native.so')
process.memory instanceof ArrayBuffer
process.memory.transferToImmutable() // or .detach()

Is this a case we want the host to be able to reject the detached behavior? (This also affects other APIs like transfer actually).

@ljharb
Copy link
Member

ljharb commented Dec 24, 2024

I'm confused, how would this not work out of the box? If it's actually a proper instance of ArrayBuffer, then it'd be detachable; if it's not detachable, then it's not a proper instance of ArrayBuffer.

@Jack-Works
Copy link
Member Author

I'm confused, how would this not work out of the box? If it's actually a proper instance of ArrayBuffer, then it'd be detachable; if it's not detachable, then it's not a proper instance of ArrayBuffer.

I mean, if there is a case that the host wants to reject the AB being detachable. this is like HostEnsureCanAddPrivateElement that limits the ability of adding a private field to a host object.

@ljharb
Copy link
Member

ljharb commented Dec 25, 2024

Why would we want to consider a host hook when no use case for that has presented itself?

@Jamesernator
Copy link

Jamesernator commented Dec 26, 2024

I'm confused, how would this not work out of the box? If it's actually a proper instance of ArrayBuffer, then it'd be detachable; if it's not detachable, then it's not a proper instance of ArrayBuffer.

Why would we want to consider a host hook when no use case for that has presented itself?

Host buffers can already be non-detachable/transferable via [[ArrayBufferDetachKey]], e.g. WebAssembly.Memory can't be transfered/detached (except via other WebAssembly methods, e.g. mem.grow does detach the previous buffer):

const mem = new WebAssembly.Memory({ initial: 1 });
// Throws a TypeError
const newBuffer = mem.buffer.transfer();
const oldBuffer = mem.buffer;
mem.grow(1);
// Now detached
oldBuffer.detached; // true
oldBuffer === mem.buffer; // false

const mem = new WebAssembly.Memory({ initial: 1, maximum: 1 });
// Not detachable by any means
mem.buffer;

I don't see that this proposal needs anything special, if a host buffer can't be transfered to an immutable buffer then they can just set [[ArrayBufferDetachKey]] and provide a separate API.

@Jack-Works
Copy link
Member Author

Thank you! This is first time I learn ArrayBufferDetachKey

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

No branches or pull requests

3 participants