This isn't so much of a Python issue as a Django issue - there are many ways in Python (and indeed most languages) of watching for a time to pass, but the problem is how you act upon it. With Django and websockets you'll need to tell it to send data down an existing websocket, and how to do that will depend on how exactly the websockets are implemented (which in turn is likely to depend on Django).

A threaded approach that is more effective than having one per timer is to have one timer thread manage all the timers. Keep a list of timers and game IDs and sort them by time, ascending. Then you only have to check the first timer to see if it's expired; if so, send a signal to that game, pop it from the list, and repeat. If the first timer has not expired, you can have that thread sleep for a while. The first complication with this approach is safely getting a timer into the thread, but you can probably use the Queue module to help there. The second complication, as hinted at in the first paragraph, is how to go from knowing a move has timed-out to actually notifying a player. You'd need some way of communicating back to the main Django thread, which is not simple, and it appears that most developers have to resort to using an external message queue. There's some discussion here: http://www.turnkeylinux.org/blog/django-celery-rabbitmq

Iterating through a list of all games and checking the timer would also work. It's unlikely to be a drain on resources unless you're doing it every millisecond. I don't know if there's any way to get Django to perform a task such as this every so often (eg. once a second) but the answers to this question are not very encouraging.

The unfortunate answer is that web applications are poorly suited to real-time systems like this. They're usually configured in a way that makes it difficult to respond at arbitrary times and the HTTP protocol makes it difficult to send that response even if you managed to form it. (This doesn't apply so much to Websockets - but unfortunately you're stuck within the structure of the traditional web application.) You might want to consider using a different server application that features a main loop and which would allow you to have more control over executing background tasks.

This isn't so much of a Python issue as a Django issue - there are many ways in Python (and indeed most languages) of watching for a time to pass, but the problem is how you act upon it. With Django and websockets you'll need to tell it to send data down an existing websocket, and how to do that will depend on how exactly the websockets are implemented (which in turn is likely to depend on Django).

A threaded approach that is more effective than having one per timer is to have one timer thread manage all the timers. Keep a list of timers and game IDs and sort them by time, ascending. Then you only have to check the first timer to see if it's expired; if so, send a signal to that game, pop it from the list, and repeat. If the first timer has not expired, you can have that thread sleep for a while. The first complication with this approach is safely getting a timer into the thread, but you can probably use the Queue module to help there. The second complication, as hinted at in the first paragraph, is how to go from knowing a move has timed-out to actually notifying a player. You'd need some way of communicating back to the main Django thread, which is not simple, and it appears that most developers have to resort to using an external message queue. There's some discussion here: http://www.turnkeylinux.org/blog/django-celery-rabbitmq

Iterating through a list of all games and checking the timer would also work. It's unlikely to be a drain on resources unless you're doing it every millisecond. I don't know if there's any way to get Django to perform a task such as this every so often (eg. once a second) but the answers to this question are not very encouraging.

The unfortunate answer is that web applications are poorly suited to real-time systems like this. They're usually configured in a way that makes it difficult to respond at arbitrary times and the HTTP protocol makes it difficult to send that response even if you managed to form it. (This doesn't apply so much to Websockets - but unfortunately you're stuck within the structure of the traditional web application.) You might want to consider using a different server application that features a main loop and which would allow you to have more control over executing background tasks.