Consider moving to a single daemon thread (and shared worker) for the asset watcher

[kezabelle]

If I move to a single daemon thread for the watching, and have N active requests (tabs) open doing essentially, while True: queue.get(...) is that going to be better for my battery life/power usage than N watchers?

I'm pondering this because for django-technicalerrors I kind of want to toy with using django-pattern-library which fulfils an idea I had long ago quite nicely by the look of it (yay). Except it loads all components as iframes, so I'd end up with 1+N SSE connections.

This might also fit with the notion of using a shared worker, which IIRC @adamchainz's django-browser-reload uses; It looks like each "port" is a tab, so I could send messages to them all with 1 worker, and thus still one long-lived request...maybe?

Need to investigate the trade-offs. Debugging a shared worker looks painful, but would get me 1 request per connected browser I guess. N watchers is what I currently have (hi, would you like to stat lots of files?) 1 watcher + N requests spinning on queues is a middle-ground which could be better or worse, IDK :D

Could be kinda grim to re-factor now, though. Hmmm.

[adamchainz]

This might also fit with the notion of using a shared worker, which IIRC @adamchainz's django-browser-reload uses; It looks like each "port" is a tab, so I could send messages to them all with 1 worker, and thus still one long-lived request...maybe?

Yes this is exactly how django-browser-reload works.

Debugging a shared worker looks painful,

I couldn't find the worker's log messages in Chrome. But in Firefox they seem to route to the console of the tab that opened the worker, so not so bad.

[kezabelle]

Ah you're a gem for stopping by to fill in some gaps and unknowns for me, thanks so much. It looks like you can also summon the devtools for a shared worker in Chrome through a magic portal page, so maybe that'd make things less irksome too.

[adamchainz]

Fantastic!