1 # v8+: Node.js addon C++ to C boundary layer
2
3 This layer offers a way to write at least simple Node.js addons in C without
4 all the horrible C++ goop you'd otherwise be expected to use. That goop
5 still exists, but you don't have to write it. More importantly, you can
6 write your module in a sane programming environment, avoiding the confusing
7 and error-prone C++ semantics.
8
9 ## Usage
10
11 Unlike most Node.js modules, v8+ does nothing by itself. It is intended to
12 be used as a build-time dependency of your native addon, providing you with
13 an alternate programming environment.
14
15 For full docs, read the source code.
16
17 ## Node.js Support
18
19 v8+ works with, and has been tested to some extent with, Node.js 0.6.18 and
20 0.8.1. It most likely works with other micro versions in the 0.6 and 0.8
21 series as well. Note that this does not mean you can necessarily expect an
22 addon built against a particular minor release of Node.js to work with any
23 other minor release of Node.js.
24
25 ## Building and Installing
26
27 The v8+ source code is compiled into your module directly along with your
28 code. There is no separate v8+ library or node module, so the v8+ source,
29 tools, and makefiles are required to be present at the time your module is
30 built. They are not required at runtime.
31
32 Normally, your addon module will depend on the v8plus package and install it
33 using npm. The v8+ makefiles are set up to accommodate the installation of
34 v8+ anywhere `node(1)` would be able to find it using `require()` if it were
35 a normal JavaScript module, so simply including it as a dependency in your
36 `package.json` will work correctly. In addition, you will need to create a
37 (normally trivial) makefile for your module that includes the makefiles
38 distributed as part of v8+. Once you have done so, it is sufficient to run
39 `gmake` to generate the native loadable module used by Node.js.
40
41 The overall outline for creating a v8+ module looks something like this:
42
43 1. Write the C code that does whatever your module does. Be sure to
44 \#include "v8plus_glue.h". Do not include any other v8+ headers.
45
46 2. Create an appropriate `package.json` file. See below for details.
47
48 3. Create a skeleton makefile. See below for details.
49
50 4. Create a JSON file defining the error codes your module will use. See
51 Errors below.
52
53 You should not (and need not) modify either of the delivered makefiles;
54 override the definitions in Makefile.v8plus.defs in your makefile as
55 appropriate.
56
57 ### Packaging Considerations
58
59 There are two essential properties your `package.json` must contain in order
60 to use v8+ with npm:
61
62 1. A dependency on `v8plus`.
63
64 2. An appropriate script entry for building your module. It is strongly
65 recommended that you use something like the following:
66
67 "postinstall": "gmake $(eval echo ${MAKE_OVERRIDES})"
68
69 This will allow someone building your module to set make variables by adding
70 them to the `MAKE_OVERRIDES` environment variable; e.g.,
71
72 $ MAKE_OVERRIDES="CTFCONVERT=/bin/true CTFMERGE=/bin/true" npm install
73
74 ### Tying into the Makefiles
75
76 The makefiles shipped with v8+ do the great majority of the heavy lifting
77 for you. A minimally functional makefile for your addon must contain four
78 things:
79
80 1. Variable definitions for `V8PLUS` and `PREFIX_NODE`. Alternately, you
81 may choose to provide these on the command line or via the environment.
82 It is recommended that these assignments be made exactly as follows,
83 which will cause the addon to be built against the `node` that is found
84 first in your path:
85
86 PREFIX_NODE := $(shell dirname `bash -c 'hash node; hash -t node'`)/..
87 V8PLUS := $(shell $(PREFIX_NODE)/bin/node -e 'require("v8plus");')
88
89 Note that the mechanism for finding `node` will not work correctly if
90 yours is a symlink. This invocation of node(1) uses a v8+ mechanism to
91 locate v8+ sources anywhere that node(1) can find them and should not be
92 modified unless you want to test an alternate v8+.
93
94 2. The exact line:
95
96 include $(V8PLUS)/Makefile.v8plus.defs
97
98 3. Variable assignments specific to your module. In particular, you must
99 define `SRCS`, `MODULE`, and `ERRNO_JSON`. Additional customisation is
100 optional.
101
102 4. The exact line:
103
104 include $(V8PLUS)/Makefile.v8plus.targ
105
106 Additional arbitrary customisation is possible using standard makefile
107 syntax; most things that are useful to change already have variables defined
108 in `Makefile.v8plus.defs` whose values you may append to or override. For
109 example, you may cause additional system libraries to be linked in by
110 appending `-lname` to the `LIBS` variable. By default, the makefiles assume
111 that your sources are located in the `src` subdirectory of your module, and
112 that you want the sole output of the build process to be called
113 `$(MODULE).node` and located in the `lib` subdirectory. This can be changed
114 by overriding the `MODULE_DIR` variable.
115
116 A simple example makefile may be found in the `examples/` subdirectory, and
117 additional examples may be found in existing consumers; see Consumers below.
118 The GNU people also provide a good manual for make if you get really stuck;
119 see <http://www.gnu.org/software/make/manual/make.html>. In general,
120 writing the necessary makefile fragment is expected to be as easy as or
121 easier than the equivalent task using `node-waf` or `node-gyp`, so if you're
122 finding it unexpectedly difficult or complicated there's probably an easier
123 way.
124
125 The makefiles follow GNU make syntax; other makes may not work but patches
126 that correct this are generally welcome (in particular, Sun make and GNU
127 make have different and incompatible ways to set a variable from the output
128 of a shell command, and there is no way I know to accommodate both).
129
130 ### Binary Interface
131
132 By default, the resulting object is linked with the `-zdefs` option, which
133 will cause the build to fail if any unresolved symbols remain. In order to
134 accommodate this, a mapfile specifying the available global symbols in your
135 `node` binary is automatically generated as part of the build process. This
136 makes it much easier to debug missing libraries; otherwise, a module with
137 unresolved symbols will fail to load at runtime with no useful explanation.
138 Mapfile generation probably works only on illumos-derived systems. Patches
139 that add support for other linkers are welcome.
140
141 Your module will have all symbols (other than `init`, which is used directly
142 by Node.js) reduced to local visibility, which is strongly recommended. If
143 for some reason you want your module's symbols to be visible to Node.js or
144 to other modules, you will have to modify the script that generates the
145 mapfile. See the `$(MAPFILE)` target in `Makefile.v8plus.targ`.
146
147 ## API
148
149 Your module is an object factory that instantiates and returns native
150 objects, to which a fixed set of methods is attached as properties. The
151 constructor, destructor, and methods all correspond 1-1 with C functions.
152 In addition, you may create additional class methods associated with the
153 native module itself, each of which will also have a 1-1 relationship to a
154 set of C functions.
155
156 This functionality is generally sufficient to interface with the system in
157 useful ways, but it is by no means exhaustive. Architectural limitations
158 are noted throughout the documentation.
159
160 Subsequent sections describe the API in greater detail, along with most of
161 the C functions that v8+ provides. Some utility functions may not be listed
162 here; see `v8plus_glue.h` for additional commentary and functions that are
163 available to you.
164
165 ### Constructors, Methods, and Functions
166
167 The interface between your module and v8+ consists of a handful of objects
168 with fixed types and names. These are:
169
170 const v8plus_c_ctor_f v8plus_ctor = my_ctor;
171 const v8plus_c_dtor_f v8plus_dtor = my_dtor;
172 const char *v8plus_js_factory_name = "_new";
173 const char *v8plus_js_class_name = "MyObjectBinding";
174 const v8plus_method_descr_t v8plus_methods[] = {
175 {
176 md_name: "_my_method",
177 md_c_func: my_method
178 },
179 ...
180 };
181 const uint_t v8plus_method_count =
182 sizeof (v8plus_methods) / sizeof (v8plus_methods[0]);
183
184 const v8plus_static_descr_t v8plus_static_methods[] = {
185 {
186 sd_name: "_my_function",
187 sd_c_func: my_function
188 },
189 ...
190 };
191 const uint_t v8plus_static_method_count =
192 sizeof (v8plus_static_methods) / sizeof (v8plus_static_methods[0]);
193
194 All of these must be present even if they have zero length or are NULL. The
195 prototypes and semantics of each function type are as follows:
196
197 ### nvlist_t *v8plus_c_ctor_f(const nvlist_t *ap, void **opp)
198
199 The constructor is responsible for creating the C object corresponding to
200 the native JavaScript object being created. It is not a true constructor in
201 that you are actually an object factory; the C++ function associated with
202 the JavaScript constructor is called for you. Your encoded arguments are in
203 `ap`. Allocate and populate a C object, stuff it into `*opp`, and return
204 `v8plus_void()`. If you need to throw an exception you can do so by
205 returning `v8plus_error()` or one of its wrappers, or by setting
206 `_v8plus_errno` using one of those functions and then returning an nvlist
207 with an `err` member representing a decorated exception.
208
209 ### void v8plus_c_dtor_f(void *op)
210
211 Free the C object `op` and anything else associated with it. Your object is
212 going away. This function may be empty if the constructor did not allocate
213 any memory (i.e., `op` is not a pointer to dynamically allocated memory).
214
215 ### nvlist_t *v8plus_c_method_f(void *op, const nvlist_t *ap)
216
217 When the JavaScript method is called in the context of your object, the
218 corresponding C function is invoked. `op` is the C object associated with
219 the JavaScript object, and `ap` is the encoded list of arguments to the
220 function. Return an encoded object with a `res` member, or use one of the
221 error/exception patterns.
222
223 ### nvlist_t *v8plus_c_static_method_f(nvlist_t *ap)
224
225 In addition to methods on the native objects returned by your constructor,
226 you can also provide a set of functions on the native binding object itself.
227 This may be useful for providing bindings to libraries for which no object
228 representation makes sense, or that have functions that operate outside the
229 context of any particular object. Your arguments are once again encoded in
230 `ap`, and your return values are an object containing `res` or an error.
231
232 ### Argument Handling
233
234 When JavaScript objects cross the boundary from C++ to C, they are converted
235 from v8 C++ objects into C nvlists. This means that they are effectively
236 passed by value, unlike in JavaScript or in native addons written in C++.
237 The arguments to the JavaScript function are treated as an array and
238 marshalled into a single nvlist whose properties are named "0", "1", and so
239 on. Each such property is encoded as follows:
240
241 - numbers and Number objects (regardless of size): double
242 - strings and String objects: UTF-8 encoded C string
243 - booleans and Boolean objects: boolean_value
244 - undefined: boolean
245 - null: byte, value 0
246 - Objects, including Arrays: nvlist with own properties as members and the
247 member ".__v8plus_type" set to the object's JavaScript type name. Note
248 that the member name itself begins with a . to reduce the likelihood of a
249 collision with an actual JavaScript member name.
250 - JavaScript Functions are passed in a format suitable for use with
251 `nvlist_lookup_jsfunc()` and `v8plus_args()` with the V8PLUS_TYPE_JSFUNC
252 token. This type is restricted; see below.
253
254 Because JavaScript arrays may be sparse, we cannot use the libnvpair array
255 types. Consider them reserved for internal use. JavaScript Arrays are
256 represented as they really are in JavaScript: objects with properties whose
257 names happen to be integers.
258
259 Other data types cannot be represented and will result in a TypeError
260 being thrown. If your object has methods that need other argument types,
261 you cannot use v8+.
262
263 Side effects within the VM, including modification of the arguments, are
264 not supported. If you need them, you cannot use v8+.
265
266 While the standard libnvpair functions may be used to inspect the arguments
267 to a method or function, v8+ also provides the `v8plus_args()` and
268 `v8plus_typeof()` convenience functions, which simplify checking the types
269 and obtaining the values of arguments.
270
271 ### int v8plus_args(const nvlist_t *lp, uint_t flags, v8plus_type_t t, ...)
272
273 This function checks `lp` for the exact sequence of arguments specified by
274 the list of types provided in the parameter list. If `V8PLUS_ARG_F_NOEXTRA`
275 is set in `flags`, the list of arguments must match exactly, with no
276 additional arguments. The parameter list must be terminated by
277 `V8PLUS_TYPE_NONE`.
278
279 Following `flags` is a list of argument data types and, for most data types,
280 pointers to locations at which the native C value of that argument should be
281 stored. The following JavaScript argument data types are supported; for
282 each, the parameter immediately following the data type parameter must be of
283 the indicated C type. This parameter may be `NULL`, in which case the value
284 will not be stored anywhere.
285
286 - V8PLUS_TYPE_NONE: used to terminate the parameter list only
287 - V8PLUS_TYPE_STRING: char **
288 - V8PLUS_TYPE_NUMBER: double *
289 - V8PLUS_TYPE_BOOLEAN: boolean_t *
290 - V8PLUS_TYPE_JSFUNC: v8plus_jsfunc_t *
291 - V8PLUS_TYPE_OBJECT: nvlist_t **
292 - V8PLUS_TYPE_NULL: no parameter
293 - V8PLUS_TYPE_UNDEFINED: no parameter
294 - V8PLUS_TYPE_INVALID: data_type_t (see below)
295 - V8PLUS_TYPE_ANY: nvpair_t **
296 - V8PLUS_TYPE_STRNUMBER64: uint64_t *
297 - V8PLUS_TYPE_INL_OBJECT: illegal
298
299 In most cases, the behaviour is straightforward: the value pointer parameter
300 provides a location into which the C value of the specified argument should
301 be stored. If the entire argument list matches the template, each
302 argument's C value is stored in its respective location. If not, no values
303 are stored, in the return value locations, `_v8plus_errno` is set
304 appropriately, and -1 is returned.
305
306 Three data types warrant further explanation: an argument of type
307 `V8PLUS_TYPE_INVALID` is any argument that may or may not match one of the
308 acceptable types. Its nvpair data type tag is stored and the argument
309 treated as matching. The value is ignored. `V8PLUS_TYPE_STRNUMBER64` is
310 used with strings that should be interpreted as 64-bit unsigned integers.
311 If the argument is not a string, or is not parseable as a 64-bit unsigned
312 integer, the argument will be treated as a mismatch. Finally,
313 `V8PLUS_TYPE_INL_OBJECT` is not supported with `v8plus_args()`; JavaScript
314 objects in the argument list must be individually inspected as nvlists.
315
316 A simple example:
317
318 double_t d;
319 boolean_t b;
320 char *s;
321 v8plus_jsfunc_t f;
322
323 /*
324 * This function requires exactly four arguments: a number, a
325 * boolean, a string, and a callback function. It is not acceptable
326 * to pass superfluous arguments to it.
327 */
328 if (v8plus_args(ap, V8PLUS_ARG_F_NOEXTRA,
329 V8PLUS_TYPE_NUMBER, &d,
330 V8PLUS_TYPE_BOOLEAN, &b,
331 V8PLUS_TYPE_STRING, &s,
332 V8PLUS_TYPE_JSFUNC, &f,
333 V8PLUS_TYPE_NONE) != 0)
334 return (NULL);
335
336 ### v8plus_type_t v8plus_typeof(const nvpair_t *pp)
337
338 This function simply returns the v8+ data type corresponding to the
339 name/value pair `pp`. If the value's type does not match the v8+ encoding
340 rules, `V8PLUS_TYPE_INVALID` is returned. This function cannot fail and
341 does not modify `_v8plus_errno`.
342
343 ### Returning Values
344
345 Similarly, when returning data across the boundary from C to C++, a
346 pointer to an nvlist must be returned. This object will be decoded in
347 the same manner as described above and returned to the JavaScript caller
348 of your method. Note that booleans, strings, and numbers will be encoded
349 as their primitive types, not objects. If you need to return something
350 containing these object types, you cannot use v8+. Other data types
351 cannot be represented. If you need to return them, you cannot use v8+.
352
353 The nvlist being returned must have one of two members: "res", an nvpair
354 containing the result of the call to be returned, or "err", an nvlist
355 containing members to be added to an exception. You may return a value of
356 any decodable type, and likewise may decorate an exception with properties
357 of any decodable type.
358
359 For convenience, you may return v8plus_void() instead of an nvlist,
360 which indicates successful execution of a function that returns nothing.
361
362 In addition, the `v8plus_obj()` routine is available for instantiating
363 JavaScript objects to return.
364
365 ### nvlist_t *v8plus_void(void)
366
367 This function clears `_v8plus_errno` and returns NULL. This is used to
368 indicate to internal v8+ code that the method or function should not return
369 a value.
370
371 ### nvlist_t *v8plus_obj(v8plus_type_t t, ...)
372
373 This function creates and populates an nvlist conforming to the encoding
374 rules of v8+ for returning a value or creating an exception. It can be used
375 to create anything from a single encoded value to arbitrarily nested
376 objects. It is essentially the inverse of `v8plus_args()` above, with a few
377 differences:
378
379 - It cannot be used to encode invalid or illegal data types.
380 - It accepts native C values, not pointers to them.
381 - Each value must be named.
382 - It can be used to encode nested objects inline using
383 `V8PLUS_TYPE_INL_OBJECT`, followed by type, name, value triples,
384 terminated with `V8PLUS_TYPE_NONE`.
385
386 This function can fail due to out-of-memory conditions, invalid or
387 unsupported data types, or, most commonly, programmer error in casting the
388 arguments to the correct type. *It is extremely important that data values,
389 particularly integers, be cast to the appropriate type (double) when passed
390 into this function!*
391
392 Following is a list of types and the C data types corresponding to their
393 values:
394
395 - V8PLUS_TYPE_NONE: used to terminate the parameter list only
396 - V8PLUS_TYPE_STRING: char *
397 - V8PLUS_TYPE_NUMBER: double
398 - V8PLUS_TYPE_BOOLEAN: boolean_t
399 - V8PLUS_TYPE_JSFUNC: v8plus_jsfunc_t
400 - V8PLUS_TYPE_OBJECT: nvlist_t *
401 - V8PLUS_TYPE_NULL: no parameter
402 - V8PLUS_TYPE_UNDEFINED: no parameter
403 - V8PLUS_TYPE_ANY: nvpair_t *
404 - V8PLUS_TYPE_STRNUMBER64: uint64_t
405 - V8PLUS_TYPE_INL_OBJECT: NONE-terminated type/value list
406
407 A simple example, in which we return a JavaScript object with two members,
408 one number and one embedded object with a 64-bit integer property. Note
409 that if this function fails, we will return `NULL` with `_v8plus_errno` set
410 appropriately, so v8+ will generate and throw an appropriate exception.
411
412 int x;
413 const char *s;
414
415 ...
416 return (v8plus_obj(
417 V8PLUS_TYPE_INL_OBJECT, "res",
418 V8PLUS_TYPE_NUMBER, "value", (double)x,
419 V8PLUS_TYPE_INL_OBJECT, "detail",
420 V8PLUS_TYPE_STRNUMBER64, "value64", s,
421 V8PLUS_TYPE_NONE,
422 V8PLUS_TYPE_NONE,
423 V8PLUS_TYPE_NONE));
424
425 The JSON representation of this object would be:
426
427 {
428 "res": {
429 "value": <x>,
430 "detail": {
431 "value64": "<s>"
432 }
433 }
434 }
435
436 ### v8plus_obj_setprops(nvlist_t *lp, v8plus_type_t t, ...)
437
438 You can also add or replace the values of properties in an existing nvlist,
439 whether created using `nvlist_alloc()` directly or via `v8plus_obj()`. The
440 effect is very similar to `nvlist_merge()`, where the second list is created
441 on the fly from your argument list. The interpretation of the argument list
442 is the same as for `v8plus_obj()`, and the two functions are implemented
443 using the same logic.
444
445 ### Exceptions
446
447 If you are unable to create an nvlist to hold exception data, or you want a
448 generic exception to be thrown, return the value returned by v8plus_error().
449 In this case, the error code will be translated to an exception type and the
450 message string will be used as the message member of the exception. Other
451 members will not be present in the exception unless you also return an
452 nvlist containing an 'err' member (or, from a constructor, any nvlist) Only
453 basic v8-provided exception types can be thrown; if your addon needs to
454 throw some other kind of exception, you will need to either use v8 directly
455 or catch and re-throw from a JavaScript wrapper.
456
457 ## Errors
458
459 The v8plus_errno_t enumerated type and a family of utility functions are
460 automatically generated by generrno.js from a simple JSON file. The schema
461 of this file is as follows:
462
463 {
464 "error_base": <string>,
465 "errors": [
466 {
467 "code": <string>,
468 "msg": <string>,
469 "exception": <string>
470 },
471 ... ]
472 }
473
474 For each entry in the errors array, an identifier V8PLUSERR_code will be
475 added to v8plus_errno_t. By convention, code should be all upper case. The
476 default error message (present in JavaScript exceptions if a more specific
477 error message is not provided to v8plus_error()) is given by the msg
478 property. The exception property must be one of "Error", "TypeError",
479 "ReferenceError", "RangeError", or "SyntaxError"; i.e., the standard
480 exception types available in v8. This is the type of exception that will be
481 generated and thrown when a C function returns NULL with this error code
482 set. In addition, the built-in error codes V8PLUSERR_NOMEM,
483 V8PLUSERR_YOUSUCK, and V8PLUSERR_UNKNOWN are available for your use,
484 indicating an out of memory condition, programmer error (e.g., failure of
485 something you would assert in JavaScript), and an error code that cannot be
486 translated, respectively.
487
488 Set the make variable ERRNO_JSON to the name of this file.
489
490 To set the value of `_v8plus_errno`, use one of the following functions. It
491 is a bug to manipulate this variable directly.
492
493 ### nvlist_t *v8plus_verror(v8plus_errno_t e, const char *fmt, va_list)
494
495 This is the varargs analogue to `v8plus_error()` and has identical
496 semantics. Use this if you want to wrap manipulation of the v8+ error state
497 within your own varargs functions.
498
499 ### nvlist_t *v8plus_error(v8plus_errno_t e, const char *fmt, ...)
500
501 This function sets the value of `_v8plus_errno` to `e` and sets the
502 associated error message string to the formatted string `fmt` using the
503 argument list that follows. The format string and arguments are interpreted
504 as by `vsnprintf(3c)`. NULL is returned, suitable for returning directly
505 from a C function that provides a method if no exception decoration is
506 required.
507
508 If `fmt` is NULL, a generic default message is used; for consumer-defined
509 error codes, that message is the one provided in `errno.json`.
510
511 ### nvlist_t *v8plus_nverr(int errno, const char *propname)
512
513 This function sets the value of `_v8plus_errno` to a value mapped from the
514 system error code `errno` and sets the error message to a non-localised
515 explanation of the problem. The string `propname`, if non-NULL, is
516 indicated in the message as the name of the nvlist property being
517 manipulated when the error occurred. NULL is returned.
518
519 ### nvlist_t *v8plus_syserr(int errno, const char *fmt, ...)
520
521 Analogous to `v8plus_error()`, this function instead sets the error code to
522 a mapped value derived from the system error code `errno`. Not all error
523 codes can be mapped; those that are not known are mapped onto
524 `V8PLUSERR_UNKNOWN`. This function's semantics are otherwise identical to
525 those of `v8plus_error()`.
526
527 ### void v8plus_panic(const char *fmt, ...) __NORETURN
528
529 This function indicates a fatal runtime error. The format string `fmt` and
530 subsequent arguments are interpreted as by `vsnprintf(3c)` and written to
531 standard error, which is then flushed. `abort(3c)` or similar is then
532 invoked to terminate the Node.js process in which the addon is running. Use
533 of this function should be limited to those circumstances in which an
534 internal inconsistency has been detected that renders further progress
535 hazardous to user data or impossible.
536
537 ### Asynchrony
538
539 There are two main types of asynchrony supported by v8+. The first is the
540 deferred work model (using `uv_queue_work()` or the deprecated
541 `eio_custom()` mechanisms) frequently written about and demonstrated by
542 various practitioners around the world. In this model, your method or
543 function takes a callback argument and returns immediately after enqueuing a
544 task to run on one of the threads in the Node.js worker thread pool. That
545 task consists of a C function to be run on the worker thread, which may not
546 use any V8 (or v8+) state, and a function to be run in the main event loop
547 thread when that task has completed. The latter function is normally
548 expected to invoke the caller's original callback. In v8+, this takes the
549 following form:
550
551 void *
552 async_worker(void *cop, void *ctxp)
553 {
554 my_object_t *op = cop;
555 my_context_t *cp = ctxp;
556 my_result_t *rp = ...;
557
558 /*
559 * In thread pool context -- do not call any of the
560 * following functions:
561 * v8plus_obj_hold()
562 * v8plus_obj_rele()
563 * v8plus_jsfunc_hold()
564 * v8plus_jsfunc_rele()
565 * v8plus_call()
566 * v8plus_method_call()
567 * v8plus_defer()
568 *
569 * If you touch anything inside op, you may need locking to
570 * protect against functions called in the main thread.
571 */
572 ...
573
574 return (rp);
575 }
576
577 void
578 async_completion(void *cop, void *ctxp, void *resp)
579 {
580 my_object_t *op = cop;
581 my_context_t *cp = ctxp;
582 my_result_t *rp = resp;
583 nvlist_t *cbap;
584 nvlist_t *cbrp;
585
586 ...
587 cbap = v8plus_obj(
588 V8PLUS_TYPE_WHATEVER, "0", rp->mr_value,
589 V8PLUS_TYPE_NONE);
590
591 if (cbap != NULL) {
592 cbrp = v8plus_call(cp->mc_callback, cbap);
593 nvlist_free(cbap);
594 nvlist_free(cbrp);
595 }
596
597 v8plus_jsfunc_rele(cp->mc_callback);
598 free(cp);
599 free(rp);
600 }
601
602 nvlist_t *
603 async(void *cop, const nvlist_t *ap)
604 {
605 my_object_t *op = cop;
606 v8plus_jsfunc_t cb;
607 my_context_t *cp = malloc(sizeof (my_context_t));
608 ...
609 if (v8plus_args(ap, 0, V8PLUS_TYPE_JSFUNC, &cb,
610 V8PLUS_TYPE_NONE) != 0) {
611 free(cp);
612 return (NULL);
613 }
614
615 v8plus_jsfunc_hold(cb);
616 cp->mc_callback = cb;
617 v8plus_defer(op, cp, async_worker, async_completion);
618
619 return (v8plus_void());
620 }
621
622 This mechanism uses `uv_queue_work()` and as such will tie up one of the
623 worker threads in the pool for as long as `async_worker` is running.
624
625 The other asynchronous mechanism is the Node.js `EventEmitter` model. This
626 model requires some assistance from JavaScript code, because v8+ native
627 objects no not inherit from `EventEmitter`. To make this work, you will
628 need to create a JavaScript object (the object your consumers actually use)
629 that inherits from `EventEmitter`, hang your native object off this object,
630 and populate the native object with an appropriate method that will cause
631 the JavaScript object to emit events when the native object invokes that
632 method. A simple example might look like this:
633
634 var util = require('util');
635 var binding = require('./native_binding');
636 var events = require('events');
637
638 function
639 MyObjectWrapper()
640 {
641 var self = this;
642
643 events.EventEmitter.call(this);
644 this._native = binding._create.apply(this,
645 Array.prototype.slice.call(arguments));
646 this._native._emit = function () {
647 var args = Array.prototype.slice.call(arguments);
648 self.emit.apply(self, args);
649 };
650 }
651 util.inherits(MyObjectWrapper, events.EventEmitter);
652
653 Then, in C code, you must arrange for libuv to call a C function in the
654 context of the main event loop. How to do this depends on what type of
655 asynchronous event you are waiting for; for example, the `uv_poll` mechanism
656 will call you back in the appropriate context when a file descriptor becomes
657 readable or writable. Because libuv is a C library, you can easily use
658 these interfaces directly in your v8+ addon. Your libuv callback might then
659 contain code looking something like this:
660
661 nvlist_t *eap;
662 nvlist_t *erp;
663 my_object_t *op = ...;
664 ...
665 eap = v8plus_obj(
666 V8PLUS_TYPE_STRING, "0", "my_event",
667 ...,
668 V8PLUS_TYPE_NONE);
669
670 if (eap != NULL) {
671 erp = v8plus_method_call(op, "_emit", eap);
672 nvlist_free(eap);
673 nvlist_free(erp);
674 }
675
676 This example will generate an event named "my_event" and propagate it to
677 listeners registered with the `MyObjectWrapper` instance. If additional
678 arguments are associated with the event, they may be added to `eap` and will
679 also be passed along to listeners as arguments to their callbacks.
680
681 ### void v8plus_obj_hold(const void *op)
682
683 Places a hold on the V8 representation of the specified C object. This is
684 rarely necessary; `v8plus_defer()` performs this action for you, but other
685 asynchronous mechanisms may require it. If you are returning from a method
686 call but have stashed a reference to the object somewhere and are not
687 calling `v8plus_defer()`, you must call this first. Holds and releases must
688 be balanced. Use of the object within a thread after releasing is a bug.
689
690 ### void v8plus_obj_rele(const void *op)
691
692 Releases a hold placed by `v8plus_obj_hold()`.
693
694 ### void v8plus_jsfunc_hold(v8plus_jsfunc_t f)
695
696 Places a hold on the V8 representation of the specified JavaScript function.
697 This is required when returning from a C function that has stashed a
698 reference to the function, typically to use it asynchronously as a callback.
699 All holds must be balanced with a release. Because a single hold is placed
700 on such objects when passed to you in an argument list (and released for you
701 when you return), it is legal to reference and even to invoke such a
702 function without first placing an additional hold on it.
703
704 ### void v8plus_jsfunc_rele(v8plus_jsfunc_t f)
705
706 Releases a hold placed by `v8plus_jsfunc_hold()`.
707
708 ### void v8plus_defer(void *op, void *ctx, worker, completion)
709
710 Enqueues work to be performed in the Node.js shared thread pool. The object
711 `op` and context `ctx` are passed as arguments to `worker` executing in a
712 thread from that pool. The same two arguments, along with the worker's
713 return value, are passed to `completion` executing in the main event loop
714 thread. See example above.
715
716 ### nvlist_t *v8plus_call(v8plus_jsfunc_t f, const nvlist_t *ap)
717
718 Calls the JavaScript function referred to by `f` with encoded arguments
719 `ap`. The return value is the encoded return value of the function. The
720 argument and return value encoding match the encodings that are used by C
721 functions that provide methods.
722
723 ### nvlist_t *v8plus_method_call(void *op, const char *name, const nvlist_t *ap)
724
725 Calls the method named by `name` in the native object `op` with encoded
726 argument list `ap`. The method must exist and must be a JavaScript
727 function. Such functions may be attached by JavaScript code as in the event
728 emitter example above. The effects of using this function to call a native
729 method are undefined.
730
731 ## FAQ
732
733 - Why?
734
735 Because C++ is garbage. Writing good software is challenging enough without
736 trying to understand a bunch of implicit side effects or typing templated
737 identifiers that can't fit in 80 columns without falling afoul of the
738 language's ambiguous grammar. Don't get me started.
739
740 - Why not use [FFI](https://github.com/rbranson/node-ffi)?
741
742 FFI is really cool; it offers us the ability to use C libraries without
743 writing bindings at all. However, it also exposes a lot of C nastiness to
744 JavaScript code, essentially placing the interface boundary in consuming
745 code itself. This pretty much breaks the JavaScript interface model --
746 for example, you can't really have a function that inspects the types of its
747 arguments -- and requires you to write an additional C library anyway if you
748 want or need to do something natively that's not quite what the C library
749 already does. Of course, one could use it to write "bindings" in JavaScript
750 that actually look like a JavaScript interface, which may end up being the
751 best answer, especially if those are autogenerated from CTF! In short, v8+
752 and FFI are different approaches to the problem. Use whichever fits your
753 need, and note that they're not mutually exclusive, either.
754
755 - What systems can I use this on?
756
757 [illumos](http://illumos.org) distributions, or possibly other platforms
758 with a working libnvpair. I'm sorry if your system doesn't have it; it's
759 open source and pretty easy to port.
760
761 There is an OSX port; see [the ZFS port's
762 implementation](http://code.google.com/p/maczfs/source/browse/#git%2Fusr%2Fsrc%2Flib%2Flibnvpair).
763 Unfortunately this port lacks the requisite support for floating-point data
764 (DATA_TYPE_DOUBLE) but you could easily add that from the illumos sources.
765
766 - What about node-waf and node-gyp?
767
768 Fuck python, fuck WAF, and fuck all the hipster douchebags for whom make is
769 too hard, too old, or "too Unixy". Make is simple, easy to use, and
770 extremely reliable. It was building big, important pieces of software when
771 your parents were young, and it Just Works. If you don't like using make
772 here, you probably don't want to use v8+ either, so just go away. Write
773 your CoffeeScript VM in something else, and gyp-scons-waf-rake your way to
774 an Instagram retirement in Bali with all your hipster douchebag friends.
775 Just don't bother me about it, because I don't care.
776
777 - Why is Node failing in dlopen()?
778
779 Most likely, your module has a typo or needs to be linked with a library.
780 Normally, shared objects like Node addons should be linked with -zdefs so that
781 these problems are found at build time, but Node doesn't deliver a mapfile
782 specifying its API so you're left with a bunch of undefined symbols you just
783 have to hope are defined somewhere in your node process's address space. If
784 they aren't, you're boned. LD_DEBUG=all will help you find the missing
785 symbol(s).
786
787 As of 0.0.2, v8+ builds a mapfile for your node binary at the time you build
788 your addon. It does not attempt to restrict the visibility of any symbols,
789 so you will not be warned if your addon is using private or deprecated
790 functionality in V8 or Node.js. Your build will, however, fail if you've
791 neglected to link in any required libraries, typo'd a symbol name, etc.
792
793 - Why use the old init() instead of NODE_MODULE()?
794
795 Because NODE_MODULE() is a macro that can't be passed another macro as the
796 name of your addon. Using it would therefore require the source to v8+ to
797 be generated at build time to match your module's name, which is
798 inconvenient. There may be a way to work around this.
799
800 - Why can't I see my exception's decorative properties in JavaScript?
801
802 Be careful when decorating exceptions. There are several built-in hidden
803 properties; if you decorate the exception with a property with the same
804 name, you will change the hidden property's value but it will still be
805 hidden. This almost certainly is not what you want, so you should prefix
806 the decorative property names with something unique to your module to avoid
807 stepping on V8's (or JavaScript's) property namespace.
808
809 - What if the factory model doesn't work for me?
810
811 See "License" below. Note also that one can export plain functions as well.
812
813 - Why do I always die with "invalid property type -3621" (or other garbage)?
814
815 You are passing an object with the wrong C type to `v8plus_obj()`. Like
816 all varargs functions, it cannot tell the correct size or type of the
817 objects you have passed it; they must match the preceding type argument or
818 it will not work correctly. In this particular case, you've most likely
819 done something like:
820
821 int foo = 0xdead;
822
823 v8plus_obj(V8PLUS_TYPE_NUMBER, "foo", foo, V8PLUS_TYPE_NONE);
824
825 An 'int' is 4 bytes in size, and the compiler reserves 4 bytes on the stack
826 and sticks the value of foo there. When `v8plus_obj` goes to read it, it
827 sees that the type is V8PLUS_TYPE_NUMBER, casts the address of the next
828 argument slot to a `double *`, and dereferences it, then moves the argument
829 list pointer ahead by the size of a double. Unfortunately, a double
830 is usually 8 bytes long, meaning that (a) the value of the property is going
831 to be comprised of the integer-encoded foo appended to the next data type,
832 and (b) the next data type is going to be read from either undefined memory
833 or from part of the address of the name of the next property. To cure this,
834 always make sure that you cast your integral arguments properly when using
835 V8PLUS_TYPE_NUMBER:
836
837 v8plus_obj(V8PLUS_TYPE_NUMBER, "foo", (double)foo, V8PLUS_TYPE_NONE);
838
839 ## License
840
841 MIT.
842
843 ## Bugs
844
845 See <https://github.com/wesolows/v8plus/issues>.
846
847 ## Consumers
848
849 This is an incomplete list of native addons known to be using v8+. If your
850 addon uses v8+, please let me know and I will include it here.
851
852 - <https://github.com/wesolows/node-contract>