Thoughts on a synchronous rcl.init() function

[wayneparrott]

Presently rcl.init() (see index.js) is an asynchronous function due to it's file system access to detect format changes in generated message files. I would like to open a discussion around the idea of adding a synchronous version of init(), e.g., rcl.initSync(), rcl.basicInit() or rcl.fastInit(), which either does not perform file system access or includes the ability to opt out of automatic message version check and regeneration.

A use-case is the rate.js implementation that creates a private rcl environment using it's own context. Because the implementation has to call rcl.init(privateContext) the Node.createRate() method is unnecessarily async. I say unnecessarily async because rate.js has no dependencies on generated msg files yet it inherits that overhead from rcl.init().

Thoughts?

One impl may look like this:

let rcl = {
...
  fastInit(context=Context.defaultContext(), argv=process.argv) {
    // check if context has already been initialized
    if (!context.isUninitialized()) {
      throw new Error('The context has already been initialized.');
    }

    // check argv for correct value and state
    if (!Array.isArray(argv)) {
      throw new TypeError('argv must be an array.');
    }
    if (!argv.every((argument) => typeof argument === 'string')) {
      throw new TypeError('argv elements must be strings (and not null).');
    }

    rclnodejs.init(context.handle, argv);
  },

  async init(context=Context.defaultContext(), argv=process.argv) {
    this.fastInit(context, argv);
    
    // do version check and update of generated msg files
  },

  ...
}
    

[minggangw]

I think using Rate only is a specific case for the usage of rclnodejs and what we need is kind of lazy init. We could consider

• During start up: only init Context.
• During running: if we need to access the generated JS messages and we are going to check/generate them.

My concern is that whether this kind of change will influence the user experience/real-time performance, e.g. When publishing a topic and the JS messages are not there, the time consumption of generating messages may be not acceptable during run time.