Yes, we already use extensively multithreaded JS with different contexts. We also sometimes use different runtimes for different functions. Earlier internal non-SCXML "state machines" implemented in code didn't give that clean protection of data exchange (people would have guard functions that would actually change state data or have other threads change data outside the state machine). It can be a mixed blessing, since you have to pay a marshaling cost and it becomes moderately more expensive to share this data, but it means your state machine actually properly captures all aspects of the state (including the data exchange) which is a big win to understanding the execution and finding problems and debugging.
From: chris nuernberger [mailto:cnuernber@gmail.com]
Sent: Monday, February 11, 2013 12:14 PM
To: Michael Bodell
Cc: VBWG Public (www-voice@w3.org)
Subject: Re: Implement TCP with scxml compliant state machine
Then do you create a completely separate JS context that is independent of any other JS contexts in your system at that time? The protected data exchange sounds like a must-have actually if you want to prove anything about the system.
Chris