Skip to content

Claude/windows slowness pool error ty jcd#14

Open
offbyonebit wants to merge 3 commits into
mainfrom
claude/windows-slowness-pool-error-TyJCD
Open

Claude/windows slowness pool error ty jcd#14
offbyonebit wants to merge 3 commits into
mainfrom
claude/windows-slowness-pool-error-TyJCD

Conversation

@offbyonebit
Copy link
Copy Markdown
Owner

No description provided.

claude added 3 commits May 21, 2026 16:36
On Windows, watchdog's Observer uses WindowsApiObserver which dispatches
events through a thread pool. The old code ran file I/O and pyperclip
clipboard access synchronously inside the watchdog event handler, blocking
pool workers under load and causing pool-exhaustion errors and UI
slowness that didn't reproduce on Linux.

- Add _in_queue (SimpleQueue) and a dedicated clipsync-in thread that
  drains the queue and calls _on_file_changed. The watchdog handler now
  just puts a path on the queue and returns immediately, keeping the
  thread pool free.
- Cache resolved clipboard file paths in _ClipboardFileHandler so
  _matches() doesn't call Path.resolve() three times per event.
- Add fast name-based pre-filter before the (more expensive) resolve()
  call, since Syncthing generates many temp-file events for other files.

https://claude.ai/code/session_0128MyVVEu1Dt3jTeaZ1edyL
…ming views

_DevicesContent._refresh() and IncomingWindow._refresh() both called
connected_devices() / get_pending_devices() directly on the main thread.
Each call has a 10-second timeout and connected_devices() makes 3
sequential requests, so a slow or unresponsive Syncthing froze the entire
UI for up to 30 seconds on every auto-refresh cycle (every 3s).

- Split each _refresh() into _do_refresh() (background thread) +
  _apply_refresh() (main thread via after(0, ...)), matching the pattern
  already used by _nearby_worker.
- Catch requests.RequestException separately and show "Syncthing is not
  responding" instead of the raw HTTPConnectionPool traceback string.
- Show a "Loading…" placeholder while the fetch is in flight.

https://claude.ai/code/session_0128MyVVEu1Dt3jTeaZ1edyL
The background-thread refresh introduced in the previous commit had a
new problem: _auto_refresh fires every 3s, but connected_devices() can
take up to 30s (3 calls × 10s timeout). Without a guard, 10 overlapping
refresh threads accumulate, each making 3 requests = 30 simultaneous
requests to Syncthing's REST API, saturating it and making timeouts
self-reinforcing.

- Add _refreshing flag to _DevicesContent and IncomingWindow: a new
  fetch is skipped if one is already in flight; flag is cleared in
  _apply_refresh (or immediately if the window is gone).
- Increase auto-refresh interval 3s → 10s in both windows to reduce
  steady-state API call rate.
- Cache get_device_id() in SyncthingClient: the local device ID never
  changes, but was fetched on every connected_devices() call (every
  refresh cycle).
- Make connected_devices() resilient: if get_connections() times out,
  return devices with unknown connection status instead of raising.
- Downgrade PendingDeviceWatcher timeout logs from exception (full
  traceback) to warning: a ReadTimeout is routine when Syncthing is
  busy, not an unexpected crash.

https://claude.ai/code/session_0128MyVVEu1Dt3jTeaZ1edyL
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

Successfully merging this pull request may close these issues.

2 participants