phus/gevent-redis — Issue #4: Handling of message/subscribe responses
Author: ianepperson
Created: 2012-02-29 06:07:20+00:00
State: open

These commands never really exit, they pretty much take over the socket and prevent any other communications. The unsubscribe message should be able to halt the eternal yield, but not with this kind of return. I added a semaphore to ensure that one command wouldn't stop on another - which now pretty much ensures that a subscribe or message command will never ever be interrupted.

What do you think of modifying the message and subscribe commands such that they return gevent.queue instead? This would allow very similar functions to the currently defined functions, but would allow them to be cancelled too.

Instead of
```
for msg in redis_client.monitor(): print msg
```

You would have to:
```
mon = redis_client.monitor()
for msg in mon.get(): print msg
```

This would allow you to later send a redis_client.quit command to end the monitoring. Although this is not all that useful for the monitor, it may be very useful for subscriptions - a user could then subscribe to an event, catch the event then unsubscribe and do other things with the socket.

Maybe I'm over thinking this though. Perhaps the best thing to do in the above scenario is to open a second socket and not mess around with trying to unsubscribe the first.