Extend ctypes to permit better interaction with JSAPI from C code.

RESOLVED WONTFIX

Status

()

Core
js-ctypes
--
enhancement
RESOLVED WONTFIX
6 years ago
6 years ago

People

(Reporter: Yoric, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

JS-ctypes is very convenient to call "pure" C code from JavaScript, but that C code cannot perform advanced interactions with JavaScript, such as publishing objects with custom classes or private slots, due to two limitations:
- the C code does not have access to the JSContext;
- the C code cannot take as argument or return a JSObject.

Experience with the ongoing (re)implementation of OS.File indicates that such features could be quite useful.

Note: This looks dual to bug 592035, but the same patch could possibly solve both issues.

I am willing to mark this as a mentored bug.

Updated

6 years ago
Assignee: general → nobody
Component: JavaScript Engine → js-ctypes
QA Contact: general → js-ctypes

Comment 1

6 years ago
I am somewhat-to-very opposed to the premise of this bug. Coding against the JSAPI is not simple to begin with, and coding against the JSAPI in Javascript sounds like an engineering disaster, both for us and for the extension which will undoubtedly misuse the feature. To the extent that the OS.File implementation cannot implement its classes in JavaScript, I think we should just implement it in JSAPI, and not try to force ctypes into a role which is actively harmful.
Well, the latest version of OS.File privately reimplements a non-negligible subset of js-ctypes just for the purpose of passing arguments from JS to C++. This is rather wasteful, but I do not see any way to escape this unless such code is built into js-ctypes – short of rewriting all the serialization code for every function, which multiplies code size by about 10.
(In reply to David Rajchenbach Teller [:Yoric] from comment #2)
> Well, the latest version of OS.File privately reimplements a non-negligible
> subset of js-ctypes just for the purpose of passing arguments from JS to
> C++. This is rather wasteful, but I do not see any way to escape this unless
> such code is built into js-ctypes – short of rewriting all the serialization
> code for every function, which multiplies code size by about 10.

Are you talking about ImplicitConvert and friends? We could probably expose that stuff somehow via jsfriendapi...
Seems like if there are bits of ctypes that would be useful for you, writing raw JSAPI, then we should just make those reusable, no?
Ok, after input from Taras, I have basically reimplemented os.file purely on js-ctypes and extended js-ctypes to permit finalization (see bug 720771). So I do not require the feature covered by this bug anymore.

I am closing that bug. If someone wants to reopen it, feel free to.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.