| Age | Commit message (Collapse) | Author |
|---|
|
Replace sync_executor::block_on's reactor-less busy-spin poller with
tokio::task::block_in_place + Handle::current().block_on(), riding a
single tokio Runtime entered once in main.rs (falling back to a
disposable one when no ambient runtime exists, e.g. in tests). This
lets HttpDownloader::dispatch await CurlDownloader::download directly
instead of bouncing through the separate curl_runtime() bridge, which
is now deleted.
Manual create-project verification against the real network caught a
concurrency bug this exposed: async_fetch_file held http_downloader's
RefMut across the await on add(), which only panics once downloads
genuinely overlap. add() only needs &self, so borrow() fixes it.
With everything now sharing one real reactor, the FuturesOrdered
fan-out added for ComposerRepository::get_security_advisories/
load_async_packages finally overlaps for real: fetching 8 packages'
metadata dropped from ~7-40s to a consistent ~3-4s in a before/after
comparison, with identical resulting lock files.
sync_executor::block_on's call sites are still synchronous rather
than async fn propagated up to Command::execute, which remains the
end goal (see the TODO(phase-e) in sync_executor.rs) - nested block_on
calls elsewhere don't get this same overlap, only prevented panics.
|
|
Replaces the Job-table + tick()-driven polling loop with one async
download() that sends, decides (retry/redirect/fail/succeed via a new
decide() extracted from the former run_job), and loops until it
resolves — no more resolve/reject callbacks. The client switches from
reqwest::blocking::Client to the non-blocking reqwest::Client, with
body streaming now via tokio::fs.
Because real async I/O needs a live tokio reactor and none runs yet at
the process level (sync_executor::block_on is a no-reactor busy-spin
executor that only works when awaited futures resolve synchronously),
HttpDownloader::start_job drives CurlDownloader::download() through a
dedicated temporary current_thread Runtime (curl_runtime(), marked
TODO(phase-e)) instead. This keeps concurrency characteristics
unchanged for now — start_job still resolves one job at a time — real
parallel I/O lands once HttpDownloader/Loop are rearchitected on top of
FuturesUnordered.
count_active_jobs' curl.tick() polling and the Job.settled/curl_id
plumbing are removed as dead weight now that start_job settles curl
jobs synchronously, same as the rfs path already did.
abort_request is dropped: it had no caller (the PHP Promise-cancellation
flow it backs was never ported), and the job table it operated on no
longer exists.
Verified manually against real network I/O (sandbox disabled): `shirabe
show -a` (JSON metadata, in-memory body) and `shirabe create-project`
(actual dist zip download + extraction) both complete correctly with no
hang. Two unrelated pre-existing bugs surfaced during manual testing
(an event-dispatcher subscriber wiring gap during `require`, and a
RefCell reentrancy panic in `diagnose`) reproduce identically on the
pre-change code and are out of scope here.
|
|
The CurlDownloader owned a tokio runtime and block_on'd reqwest from its
sync tick(), while the repository/installer/downloader sync bridges each
created another Runtime and block_on'd async fns that reach that leaf.
Driving one Runtime::block_on from within another panics with "Cannot
start a runtime from within a runtime", hit by `require` when fetching
p2 metadata.
Switch CurlDownloader to a blocking reqwest client (its own internal
thread, never nested) and replace the per-call Runtime::new().block_on
bridges with a no-reactor sync_executor::block_on helper. No awaited
future parks on a reactor once the only async I/O is blocking, so the
helper can be nested freely.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
