Next API WG meeting (held Jul 14 2016)

[mhdawson]

Who

@nodejs/api

When

Meeting set for Thursday July 14 at 12 pm EST.

Where

link for participants: https://hangouts.google.com/hangouts/_/hoaevent/AP36tYenublbryPz0-q_Sjl0OZA599uDMCKR69JlkxDTeW-5BqXy2A?eid=100598160817214911030&hl=en&authuser=0

For those who just want to watch:http://www.youtube.com/watch?v=NJZ2TNul9To

Events page: https://plus.google.com/events/cvkrhrj8hfabfuho1tg5kvmeh5o

Google doc for minutes: https://docs.google.com/document/d/1iQD8JsCa-8_YJnpbd8Y2RTW7ELzY3dER8R9pzhC2fxc/edit

Agenda

• Stand up
• Actions from last meeting
• Update on work for ABI stable module API by - @ianwjhalliday, @sampsongao and @mhdawson
• Open issues review

Quick Links

Links to the code shown in the meeting:

• node fork (look at src/node_jsvmapi.h et al)
• node-addon-examples fork converted to use napi (look at abi folder under each example)
• leveldown fork converted to use napi

[mhdawson]

@nodejs/api - please complete http://doodle.com/poll/c435avwnbpdgid8h to help choose a time for the next meeting.

[mhdawson]

FYI for some people not part of the group @Fishrock123, @jasnell, @kkoopa

[mhdawson]

@nodejs/api last call to update your availability in the doodle

[mhdawson]

@nodejs/api @Fishrock123 @jasnell @kkoopa meeting set for Meeting set for Thursday July 14 at 12 pm EST.

[kkoopa]

Unfortunately I cannot make it then, but I will watch the recording afterwards.

[ianwjhalliday]

Updated the issue description above with the following links for quick reference to the code that was presented today.

• node fork (look at src/node_jsvmapi.h et al)
• node-addon-examples fork converted to use napi (look at abi folder under each example)
• leveldown fork converted to use napi

[kkoopa]

The reason NAN uses Isolate::GetCurrent is Node 0.10, which did not support multiple isolates. Passing a dummy isolate around would not have been good, since it would not have done anything. Its goal has always been identical observable behavior across versions. It would be best to make a clean break and get rid of everything older than Node 4.

I did see one problem in the current proposal: conversion from JavaScript values to real types. This procedure may fail. For example, converting nan (not a number) to an integer. The only sensible way of dealing with this is by returning an error code and using an out arg:

NODE_EXTERN int napi_get_value_uint32(napi_env e, napi_value v, uint32_t *r);

With this comes the problem of API uniformity: an out arg is not strictly necessary when going the other way, since a null pointer acts as a sentinel in a reasonable way, provided that you only ever need a single error code. But them the conversion API will be asymmetric.

[kkoopa]

napi_release_persistent leaks memory, since it operates on objects of type v8::Persistent<v8::Value, v8::NonCopyablePersistentTraits>, which do not have kResetInDestructor set, without resetting them.

Regarding ObjectWrap, it is the garbage collector that is responsible for cleaning up instances. For this to work, the persistent handle needs to be made weak.

[mhdawson]

@kkoopa thanks for the comments, will take a look at how we address them.

[mhdawson]

@nodejs/api PR for minutes from meeting: #24

[ianwjhalliday]

Thanks @kkoopa! First thing I ran into when running the benchmarks was what would have been a mysterious memory leak. Adding the Reset() call before deleting the persistent fixed that right up.

[ianwjhalliday]

@kkoopa indeed we know we need to add some sort of error handling pattern to the API. This is something we have ignored for now but we have been figuring the best approach will be error codes. On the point of consistency I think returning an error code from every API is the way to go, and all other return values will be out parameters.

I did see one problem in the current proposal: conversion from JavaScript values to real types. This procedure may fail. For example, converting nan (not a number) to an integer. The only sensible way of dealing with this is by returning an error code and using an out arg:

NODE_EXTERN int napi_get_value_uint32(napi_env e, napi_value v, uint32_t *r);

With this comes the problem of API uniformity: an out arg is not strictly necessary when going the other way, since a null pointer acts as a sentinel in a reasonable way, provided that you only ever need a single error code. But them the conversion API will be asymmetric.