ensure preload modules are always preloaded

[bmeck]

For consistency -r/--require should always preload modules; right now it works with normal startup, cluster, and eval; having preloading work with stdin and interactive mode would make this more consistent.

[thefourtheye]

Will it have impact on startup time?

[Fishrock123]

Will it have impact on startup time?

No not really.

[bmeck]

@thefourtheye only when the flag is enabled, otherwise we are looking at a few integer checks for preloaded_module_count

[Fishrock123]

CI: https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/201/

[Fishrock123]

Test is failing on smartos-14 (32 and 64bit):

not ok 535 - test-preload.js
# 
# assert.js:89
# throw new assert.AssertionError({
# ^
# AssertionError: '' == 'A\nhello\n'
# at ChildProcess.<anonymous> (/home/iojs/build/workspace/iojs+pr+other/nodes/smartos14-64/test/parallel/test-preload.js:78:10)
# at emitTwo (events.js:87:13)
# at ChildProcess.emit (events.js:172:7)
# at Process.ChildProcess._handle.onexit (internal/child_process.js:200:12)

[bmeck]

@Fishrock123 even without this patch it should never be empty... that is... concerning

[Fishrock123]

cc @nodejs/platform-solaris

[bmeck]

is there a person I can talk to about this, as I don't run SmartOS normally, and am completely lost as to how it could be empty/worked prior to this.

[Fishrock123]

cc @jbergstroem / @misterdjules again

[Fishrock123]

CI again https://jenkins-iojs.nodesource.com/job/node-test-pull-request/119/

[Fishrock123]

Seems fine to me. @bmeck how do you feel about just ignoring it on smartos?

[thefourtheye]

The commit message is too long and commit log has to be improved.

[bmeck]

@thefourtheye improved how

[Fishrock123]

I think we'd prefer if you only const unmodified variables you add, but if you want to do these also I really don't mind.

[Fishrock123]

LGTM otherwise, I'll just add some detail to the commit description if you don't. :)

[jbergstroem]

I can reproduce this fail but haven't had time to look into it. Would appreciate if @misterdjules had a moment.

[bmeck]

rebased. uses camelcase now. repro'd fail on smartos, trying to reduce it

[bmeck]

@nodejs/platform-solaris i am unsure how to test this exactly, but is closing stdin before it is fully drained dropping the content on smartos?

[rvagg]

ping @No9, perhaps you can lend an eye to this one since you're an Illumos user?

[jbergstroem]

If anyone else is using illumos/smartos and would like to help out reviewing that'd be great!

[rvagg]

also would love to additional people to @nodejs/platform-solaris if there are any

[No9]

@rvagg I'll look in over the weekend

[jbergstroem]

@No9 would you be interested in being part of the small team of people that (in my case, at least tries to) debugs sunos stuff?

[No9]

@jbergstroem Thanks for asking
Yes I would :)

[rvagg]

added to @nodejs/platform-solaris, thanks @No9!

[mhdawson]

Failed on AIX in last night's run as well #6716

[bmeck]

This is starting to look like some sort of race condition

[mhdawson]

@bmeck @Fishrock123 on AIX it looks like a consistent failure. If it helps I can give one or both of you access to run on that machine.

[Fishrock123]

We should also skip on AIX for now then, but we do need to investigate more.

[MylesBorins]

@bmeck looks like there are some regressions here. Adding dont-land for now, but please feel free to open a PR against v4.x-staging if this should be packported

[Fishrock123]

@thealphanerd No, those are just the result of other issues.

this should be fine if it lands with #6728

[MylesBorins]

thanks @Fishrock123 will work on that later today

[MylesBorins]

@bmeck would you be willing to do a manual backport of this and #6728 ?

[bmeck]

@thealphanerd onto v4?

[MylesBorins]

indeed. It is not landing cleanly

[MylesBorins]

ping @bmeck

[bmeck]

@thealphanerd backported against v4.5.0 (no staging exists right now?) on https://github.com/bmeck/node/tree/backport-2253 , still flaky it seems after running tests

[MylesBorins]

the staging is v4.x-staging

If it is still flaky then perhaps we should just mark this don't land?

[bmeck]

@thealphanerd these are just adding tests for expected behavior, if we don't want to land it thats fine

[MylesBorins]

@bmeck if that is the case then we should land it. Would you be willing to open a PR?

[bmeck]

@thealphanerd #8340