[SoC] Week 10 Report: Integrating Node.js with ZOO-services

Momtchil Momtchev momtchil at momtchev.com
Mon Aug 22 00:54:15 PDT 2022


My report for week 10 is as follows:
    * I have found a solution for the non-blocking I/O in Node.js by 
implementing a redirection of process.stdout and process.stderr in the 
JS boostrapper:
https://github.com/mmomtchev/ZOO-Project/blob/026e4df33588848ae96d2dd9cb064151ebd7c412/zoo-project/zoo-kernel/service_internal_nodejs.cc#L526
       This allows to redirect all console output from Node.js to a 
custom user-supplied function which happens to be the previously 
unimplemented alert function from the SpiderMonkey implementation.

    * Further improvements to libnode, eliminating the hard-coded 
embedded JS code in the C++ code, replacing it with a full-featured 
bootstrap code (available in the stdio branch:
       https://github.com/mmomtchev/node/tree/stdio)
       This will allow to remove all embedded JS code from the C++ code 
in ZOO-Project as well.

    * I have implemented a cleaner and more robust solution to the stdio 
problem in libnode which currently covers only stdout and stderr. This 
currently does not include stdin which requires a very difficult and 
complex implementation since Node.js expects this stream to be 
asynchronous. I am still unsure on how to proceed:
       - Should I proceed with a simple and problematic but still usable 
implementation that can block
       - Should I simply skip stdin which won’t be needed very often
       - Or should I go for a full-blown and very complex implementation 
that can read asynchronously
       (it should be pointed that, at least in theory, writing should 
also be asynchronous, with the stream being able to signal by a callback 
when the next write should take place - but as it is far too often the 
case in the Node.js world - this detail is overlooked and applications 
simply write without waiting, accepting that they can eventually block 
at some point)
    This is something that probably does not concern ZOO-Project which 
does not use stdin (AFAIK?) but it will definitely impact any eventual 
future merge of napi-libnode into Node.js itself

    * I have completed the node-addon-api pure C++ implementation which 
allows for much easier higher-level embedding of Node.js. This still 
hasn’t been packaged in the libnode PPA package.
    * I have started working on the loading of V8 heap snapshots, but 
there hasn’t been much progress.

    My priority tasks for next week are:
    * FOSS4G presentation
    * Merge all branches, upgrade the 16.x branch to 16.17.0 and publish 
new PPA packages with all the latest features
    * Work on the V8 snapshots
    * As a stretch goal, if/when the time permits, continue looking for 
a solution for stdin

    Except the stdin problem, I am not blocked on anything.

-- 
Cordialement,
Momtchil Momtchev <momtchil at momtchev.com>



More information about the SoC mailing list