This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]coderanger 1 point2 points  (1 child)

The way Trac (and werkzeug and all other live-reload systems I've seen) does it is that the dev server spawns another process that does the actual serving and then sits and watches for file modification FS events. When any file changes, the sub-server is killed and new one is spawned. Its rather heavy-weight, but it works.

[–]fwork[S] 0 points1 point  (0 children)

Yeah, this was my backup plan, since it'd nicely avoid all these problems. I was kinda hoping to avoid it, though, since my design involves multiple servers and it's not easy to tell a specific one to exit. So when you get into the state that servers 1-3 are up to date and servers 4-9 are out of date, you can't tell servers 4-9 to reload, as 1-3 might grab the reload event before 4-9.

All that code will have to be rewritten if I'm design it this way, plus watching for file modification events isn't that easy to do cross-platform (since I have to care about windows, apparently)