(experimental) worker isolation

[FranckFreiburger]

• Version: 11.3.0
• Platform:win 7 (64)
• Subsystem:

I just wondering if this lack of isolation is expected:

new Worker(`process.env.FOO = 123`, { eval: true });
new Worker(`console.log(process.env.FOO)`, { eval: true }); // prints 123

[addaleax]

I think at the very least the documentation does not match the actual behaviour here… I think in an earlier version of the workers implementation, we did what the doc states (not allow modifications from worker threads), but it seems that right now we also allow write access?

/cc @nodejs/workers

[devsnek]

i prefer the documented behaviour

[FranckFreiburger]

@addaleax, is this behavior thread-safe ?

[addaleax]

@FranckFreiburger We access the environment variables with a mutex, both for reading and for writing, so this should be okay (at least as far as Node is concerned). But like @devsnek, I think I’d prefer the documented behaviour.

[joyeecheung]

So this is a regression? (trying to apply labels)

[addaleax]

@joyeecheung This behaviour (and the wrong docs) have been present since workers have first been released; I assume these checks went lost during a rebase or similar… so I don’t think it’s a regression, it’s just a bug?

[sagitsofan]

@addaleax I will pick this one.
Should the appropriate solution needs to block the write access to process.env and emit a warning / exception ?

[addaleax]

@sagitsofan I don’t think we want a warning or exception; rather, not installing the setters for process.env should be the most JavaScript-y solution here, I think?

[sagitsofan]

@addaleax But if we silently will not install the setters of process.env the user will think this operation have done successfully, isn't it? shouldn't a warning is the appropriate way?