process: add .stillSynchronous

[ChALkeR]

This adds a process.stillSynchronous public property to check if the process is still in synchronous state (i.e. a sync script or startup phase of an async app/server) or not.

Could be used as an additional safeguard for #28439 (refs: #28439 (comment)), could be used to fence large deprecations like #22584 (the approach there was broken as far as I remember), also refs: nodejs/help#1740 (though this does not expose the tick id, only if we got past the first one or not).

Operates very similar to --trace-sync-io, ref: #28926.
Upd: switched to perf_hooks instead.

Docs will be added soon.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[addaleax]

Not to bikeshed too much, but how about a name like process.firstTick (although that gets confusing because process.nextTick() does not escape that – which we may also want to consider a bug) or process.firstEventLoopTurn? I think those might be clearer…

[devsnek]

I often have application logic that sets up across multiple ticks. Fetching info from a local server to setup the environment, etc, and I assume I'm not the only person who does that. Based on that, I really wouldn't want a random library I'm using to stop working because it assumes something about when the application's "setup" time is. We can still use this internally, but I don't think it should be exposed.

[ChALkeR]

@jasnell @addaleax I used perf_hooks now instead, it works nicely, thanks! No C++ part now.

@devsnek I don't think that this has much potential to be misused for such a purpose given the correct documentation (reasons: those changes you describe would be a semver-major for those modules, those modules would receive issues for misusing this API, also that is already possible in a simple (but less robust) way with setImmediate). But I think it could be useful for applications to analyze things and impose some safeguards on the app level.

[mscdex]

I agree stillSynchronous is a bit confusing, it makes me think it has something to do with I/O (e.g. stdout/stderr being in non-blocking mode or not). firstEventLoop or initialEventLoop would be better alternatives I think.

[BridgeAR]

Ping @ChALkeR

[ChALkeR]

@BridgeAR This got stuck on the naming. I'll just pick initialEventLoop for now.

[devsnek]

I still don't understand the motivation for this feature (same concern as my above comment).

[addaleax]

Hm … based on the discussion in #31765 – Maybe we want some kind of generic “event loop turn counter”?

I think the current state of the PR here would also include process.nextTick()s from the startup phase in the initialEventLoop phase, is that what we want? (In this case, “still synchronous” and “initial event loop” do refer to different things…)

[jasnell]

@ChALkeR ... still want to pursue this?

[github-actions]

Closing this because it has stalled. Feel free to reopen if this PR is still relevant, or to ping the collaborator who labelled it stalled if you have any questions.