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

Rearchitecture backend #193

Merged
merged 29 commits into from
Nov 14, 2024
Merged

Rearchitecture backend #193

merged 29 commits into from
Nov 14, 2024

Conversation

Almenon
Copy link
Owner

@Almenon Almenon commented Apr 30, 2023

See Almenon/AREPL-vscode#439. This PR ended up being different than my original concept.

I went with three executors. Each executor has the following lifecycle

flowchart TD
    P[process created] --> S[Starting] --> |Start result received| F[FreshFree] -->|incoming code| E[Executing] -->D[DirtyFree] -->|incoming code| E
Loading

When execCode is called, code will always go to a executor in the FreshFree status, so it may execute without side effects. It's possible no executor is fresh, so when new code comes in if there are dirty or executing executors they will be restarted. If no executors are in fresh status, we will wait for an executor to reach that status.

I also have a execCodeCurrent function, as one may be okay with side effects and want to reuse the current executor.

I tried to keep the API of PythonExecutors similar to the original class to minimize refactoring.

An example of how AREPL works now (assuming two executors, we use three but same principle applies):

  1. code goes to first executor, first executes and then enters DirtyFree status
  2. new code w/ infinite loop goes to second executor, second executor stuck in Executing status. First executor is restarted. At this point no executor is fresh
  3. First executor is still restarting. New code comes in, triggering restart of second executor. It waits for first executor to become fresh, which fortunately doesn't take long because python starts up fast.

At each point between 1. 2. and 3. there will be at minimum a delay of the debounce period, which is usually fast enough to make things seem snappy.

As a consequence of this change I was able to drop 108 lines of logic from arepl_python_evaluator.py. Pretty satisfying.

Unrelated to #439:

  • I updated Jsonpickle
  • I added tests for 3.12 and 3.13
  • I dropped support for 3.7, which is EOL
  • I updated various packages

@Almenon Almenon mentioned this pull request Oct 13, 2024
@Almenon
Copy link
Owner Author

Almenon commented Oct 14, 2024

fun: python/cpython#125422

@Almenon Almenon marked this pull request as ready for review November 14, 2024 06:30
@Almenon Almenon merged commit 4fea8e8 into master Nov 14, 2024
8 checks passed
@Almenon Almenon deleted the rearchitecture_backend branch November 14, 2024 07:01
Copy link

🎉 This PR is included in version 3.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

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

Successfully merging this pull request may close these issues.

1 participant