This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author josiahcarlson
Recipients MrJean1, alanmcintyre, donmez, facundobatista, giampaolo.rodola, josiahcarlson, mark.dickinson, r.david.murray
Date 2009-05-08.17:49:30
SpamBayes Score 4.3719556e-08
Marked as misclassified No
Message-id <1241804972.37.0.348125739072.issue5798@psf.upfronthosting.co.za>
In-reply-to
Content
One of the issues with using the method that Giampaolo describes, which 
I explained to him, is that generally if someone sends you data, you 
want to receive it.  You can get both data and the signal that someone 
disconnected, in particular, with asynchat's .close_when_done() method.

If you get a read signal, generally you want to try to pull more data 
before you close, because when you close, you can never get any pending 
data again.

For example, if I were to use:
  chat.send("commit\n")
  chat.close_when_done()
It's very likely that on even moderate latency network connections 
(10ms), the other end would get the close signal at the same time as the 
read for the "commit\n" message.  But since they close before they read, 
they never get the "commit" message, and maybe a transaction is 
reverted.

My primary concern is keeping the library correct.  Adding attributes in 
the test cases don't bother me.

Jean: on what platform are you experiencing the hang?  Are you using 
trunk or 3.1?
History
Date User Action Args
2009-05-08 17:49:32josiahcarlsonsetrecipients: + josiahcarlson, facundobatista, mark.dickinson, alanmcintyre, giampaolo.rodola, donmez, MrJean1, r.david.murray
2009-05-08 17:49:32josiahcarlsonsetmessageid: <1241804972.37.0.348125739072.issue5798@psf.upfronthosting.co.za>
2009-05-08 17:49:31josiahcarlsonlinkissue5798 messages
2009-05-08 17:49:30josiahcarlsoncreate