Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

interp.go: Detect "async" keyword in statements executing stage and init async interp mode. #1

Open
dalechyn opened this issue Nov 7, 2019 · 0 comments

Comments

@dalechyn
Copy link
Member

dalechyn commented Nov 7, 2019

As of now, to run script files concurrently, you have to explicitly define which ones you want to run.
If we add an async keyword, it can mark that file should be executed concurrently.
So it could look like this:

async
echo "hello there"
sync echo "hello but synchronous"

But the thing is - that I am not sure how to parse the keyword in the parsing stage. Right now I can think of a special async builtin, which pauses Runner execution, puts it to concurrent mode, and continues from where it stopped but in another goroutine. I assume it to be embedded into Runner.Run(...) function.

So overall execution of two scripts concurrently could look like this:

Main goroutine:

  • Executing scripts sequentially
  • Starts executing first script:
echo "hey"
async
sync echo "heey sync"
  • Prints "hey"
  • It meets async, runner switches to concurrent mode, resumes execution in another goroutine
  • As first script is resumed in another goroutine, main goroutine starts parsing the second file:
sleep 1
echo "script2 hey!"
async
sync echo "sync echo!"
  • Sleeps for 1 second.
  • Prints "script2 hey!".
  • It meets the async builtin again, and does the same thing as with the first script.

First goroutine:

  • Sends pause signal to RunnersManager, which blocks other Runners if any.
  • Prints "heey sync!".
  • Sends unpause signal.

Second goroutine:

  • Sends pause signal to RunnersManager.
  • Prints "seync echo!".
  • Sends unpause signal.

And as here the number of async workers will dynamically change, the channel which recieves errors in RunnersManager could be unbuffered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant