Skip to content

Conversation

@moreirathomas
Copy link
Member

@moreirathomas moreirathomas commented Aug 22, 2022

Description

Resolves the related issue by implementing the first solution suggested there. The child process (engine) finds any free port and notifies its parent of the one it found.

This allows for quicker port finding by simply asking the os (see below) instead of trying within a range and locking the port in the parent process until the child is ready to be spawned.

Finding a free port is done by asking the os for port "0", which the os interprets as "any available port".

When running the project in the browser (npm run web:dev), we cannot rely on dynamic port attribution and the server notifying the frontend client. Instead we use a port defined as an environment variable in .env.development and spawn the server with the --any-port=false flag.

Changes

  • read server address from engine message via stdout
  • wait for the engine to send a ready signal with the port to resolve spawnEngine
  • set up tauri and vite environment variables
  • use VITE_ENGINE_ADDRESS variable (prefixed to be exposed in the web view, as per the docs)

Linked issues

Resolves #6

Notes

  • Refactor how we wait for the engine to notify its ready state
  • Refactor how we pipe stdout and stderr from child process to the frontend

It is mean to be executed manually in dev mode with the browser.
Use the env port variable in that case.
@moreirathomas moreirathomas changed the title Feat/use free port engine chooses feat: use free port Aug 22, 2022
@moreirathomas moreirathomas marked this pull request as draft August 22, 2022 23:26
@moreirathomas moreirathomas added the must have Blocking feature for the targeted release label Aug 22, 2022
@moreirathomas moreirathomas linked an issue Aug 22, 2022 that may be closed by this pull request
@moreirathomas moreirathomas added this to the MVP milestone Aug 22, 2022
@moreirathomas moreirathomas marked this pull request as ready for review August 25, 2022 22:08
src/App.tsx Outdated
<div className="App">
<h1>Benchttp</h1>
{isLoading ? <div>Loading</div> : <SimpleStream />}
{isLoading ? <div>Loading</div> : <SimpleStream port={port} />}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a fan of the extensive drilling for port starting from here: useSpawnEngine ➡️ SimpleStream ➡️ useRunStream ➡️ RunStreamer ➡️ startRunStream ➡️ streamUrl

I think it's a bit much for what appears to be a configuration value, and the signature of these functions should probably not be impacted by the single fact that the port is retrieved at run time.

For these reasons I'd suggest to have an initialization step thay sets the target URL in a globally accessible configuration (e.g. engineConfiguration.baseUrl, or set a new env variable ENGINE_BASE_URL once retrieved, or any better idea) directly accessible from RunStreamer instead.

Copy link
Member Author

@moreirathomas moreirathomas Sep 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about it too when making the changes! But I went for the current implem because it was really easy to get it working.

Env variable seems to be a good candidate with low effort required.

@moreirathomas moreirathomas merged commit 12d0f9a into main Sep 5, 2022
@moreirathomas moreirathomas deleted the feat/use-free-port-engine-chooses branch September 5, 2022 12:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

must have Blocking feature for the targeted release scope:core

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Use assuredly available port for connection with engine

3 participants