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

Make racket-run connect asynchronously. #282

Closed
wants to merge 1 commit into
base: master
from

Conversation

2 participants
@technomancy

technomancy commented Oct 9, 2017

Other commands which need a connection to the racket command process
will still connect synchronously, but at least it's possible to make
the initial connection (which is usually the worst source of waiting)
without blocking the entire Emacs process.

Make racket-run connect asynchronously.
Other commands which need a connection to the racket command process
will still connect synchronously, but at least it's possible to make
the initial connection (which is usually the worst source of waiting)
without blocking the entire Emacs process.

@greghendershott greghendershott added this to Needs triage in racket-mode Jun 29, 2018

greghendershott added a commit that referenced this pull request Jul 3, 2018

Non-blocking command server connection; also async commands
- After the Racket process has been launched, we need to connect to a
  TCP server for running commands -- but the server won't immediately
  be ready to accept connections. Previously we looped and retried,
  but this blocked Emacs for awhile. Instead, use `run-with-timer' to
  repeat these attempts.

  `racket--repl-command-connect-start' starts this timer and these
  attempts. When the connection must be available (to send a command),
  `racket--repl-command-connect-finish' will wait until it is.

  A key detail is that `racket-run' itself does not actually use the
  TCP command server (it does a `process-send-string' of the ,run
  command). Therefore it need not wait -- including the very first
  `racket-run' that leads to the Racket process launching.

  This is inspired by and solves the same problem as PR #282 although
  the implementation is somewhat different.

- Use `tq' to talk to the command server. The most primitive command
  function is now `racket--repl-command-async', which takes a
  completion callback. `racket--repl-command' is just a wrapper that
  waits for the callback to be called.

  This allows us to have commands that run asynchronously -- although
  this commit doesn't yet add such a command.

greghendershott added a commit that referenced this pull request Jul 3, 2018

Non-blocking command server connection; also async commands
- After the Racket process has been launched, we need to connect to a
  TCP server for running commands -- but the server won't immediately
  be ready to accept connections. Previously we looped and retried,
  but this blocked Emacs for awhile. Instead, use `run-with-timer' to
  repeat these attempts.

  `racket--repl-command-connect-start' starts this timer and these
  attempts. When the connection must be available (to send a command),
  `racket--repl-command-connect-finish' will wait until it is.

  A key detail is that `racket-run' itself does not actually use the
  TCP command server (it does a `process-send-string' of the ,run
  command). Therefore it need not wait -- including the very first
  `racket-run' that leads to the Racket process launching.

  This is inspired by and solves the same problem as PR #282 although
  the implementation is somewhat different.

- Use `tq' to talk to the command server. The most primitive command
  function is now `racket--repl-command-async', which takes a
  completion callback. `racket--repl-command' is just a wrapper that
  waits for the callback to be called.

  This allows us to have commands that run asynchronously -- although
  this commit doesn't yet add such a command.
@greghendershott

This comment has been minimized.

Show comment
Hide comment
@greghendershott

greghendershott Jul 18, 2018

Owner

Thank you for submitting this! Around the time you did, I noticed it wasn't passing tests; I was in a busy period where I couldn't dig in to figure out why.

I ended up doing something similar in commit 1ec3c4f so I'll close this now. Thanks again!

Owner

greghendershott commented Jul 18, 2018

Thank you for submitting this! Around the time you did, I noticed it wasn't passing tests; I was in a busy period where I couldn't dig in to figure out why.

I ended up doing something similar in commit 1ec3c4f so I'll close this now. Thanks again!

racket-mode automation moved this from Needs triage to Closed Jul 18, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment