Refactor global.spawn method

[rPraml]

This PR simplifies the global.spawn function by elliminating the multifunctional Runner class.

There was no test or usage in the codebase, so I added a test (I've written a testcase, before I started to refactor)

I also added a submit function, that does effectively the same as spawn, but uses a ThreadPool instead of an own thread.

If you think, this could be useful, I can keep it

[gbrail]

I'm sure that people would find "submit" to be helpful, although at some point we should look at how other JS engines handle threads (I mean, they mostly don't, which is one thing) and see if there's a way to do this that aligns with some spec.

Also, if we want to keep "submit" -- which is fine with me -- IMO we should also update the docs for Global, which might on the separate "rhino Wiki..."

[gbrail]

I really think that this is fine. I'm not sure about the name "submit," even though that's what I know the name is in the thread pool class you're using. I'd prefer something more explicit like "runAsync".

Also, what are the semantics of this? If someone executes code to run using that new method, do we make sure that the JVM doesn't exit until it's done executing?

I wonder if a method like this might be more appropriate as part of the Shell, which is where we already have setTimeout() and a basic event-loop mechanism.

[gbrail]

Going back a little while now, but I am basically OK with it, but I'm not sold on the name "submit." I'd love to see possibly some proposals for different names, and if not, then I definitely want to go forward with at least the refactoring and testing of the spawn method!

[rPraml]

@gbrail I haven’t had much time to work on Rhino lately, so some PRs got delayed. I did a rebase though and renamed the method to runAsync.

[gbrail]

Thanks -- I like runAsync and I'm happy with this, but if we're going to add a new command I think that we should add it to the output of "help()" first. Do you think you could do that? Thanks!

[aardvark179]

I’d be very wary of calling this runAsync because I’d assume that a script run this way would be like a JS async function, i.e. I could await within it.

[aardvark179]

Should these functions check that the context has thread safe slot maps enabled, and that the context created for the spawned task also has this set? Allowing concurrent operations without enforcing that seems very dangerous.

[p-bakker]

Thanks -- I like runAsync and I'm happy with this, but if we're going to add a new command I think that we should add it to the output of "help()" first. Do you think you could do that? Thanks!

And update the docs accordingly: https://rhino.github.io/tools/shell/

[rPraml]

Thanks for the feedback, I think I will split up the refactoring part and feature extension (runAsync/submit or however we want to name it) in two separate PRs the next days

[rPraml]

I've removed the runAsync feature, so this PR focuses on refactoring.

I would add the feature again in a separate PR until it is clear

• what name should I take.
• how to update the docs. @p-bakker is creating a PR here the correct way?
• how to check for thread safe slot maps. @aardvark179 spawn is not a new feature, so the problem already exists in the code base. How should I check? log? throwing an execption? make it configurable? But I suggest to do this also in a separate PR.

[aardvark179]

cx.hasFeature(Context.FEATURE_THREAD_SAFE_OBJECTS) is what's used in SlotMapOwner to decide if it should be making thread safe maps.

[gbrail]

Thanks!