Here's an idea for a new feature. Currently, the server listens on each client socket for read events (data waiting on the wire) when it is waiting for a command, but not while it is processing a command or sending a reply. In particular this means the server doesn't try to read from the client while waiting for a reservation for that client. What if it did? Bytes on the wire could be interpreted as a desire of the client to do something else. The server could notice this, cancel the reserve command (returning TIMED_OUT), and move on to the next command.
This would be an easy way for the client to interrupt its own forever-blocking reserve command. Just issue another command. The protocol doc doesn't allow the server to send any response to a bare "reserve" command other than DEADLINE_SOON and RESERVED, both of which are clearly inappropriate. So I think the way to get this feature in 1.x would be for clients to approximate "reserve" as "reserve-with-timeout 2000000000". (Note, all of this only applies to clients that are able to do other things while waiting for a reserve response. For instance, beanstalk-client isn't unless you define a custom select method.) Does this seem like a good idea? Any problems I haven't thought of? kr --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en -~----------~----~----~----~------~----~------~--~---
