vmiklos/bitlbee — pull request #3 by mk-fg (2013-02-05 08:59:10+00:00)
Title: Basic socket send fixes

Three commits with a few things:

* Replace "while" loops with "for range", which can't produce infinite loops, also getting rid of ad-hoc vars, imports and code propping the "while".

* socket.send() -> socket.sendall() - python has latter exactly to allow people to not care whether data fit into the OS buffers or not. As check for how many bytes were sent (int returned by socket.send()) isn't done anyway, it seem to be a bug.

* Python abstracts even EINTR on sendall() (by retrying the underlying send() calls), so I see no excuse for 10s (actually, it's infinite, as no error was returned) hang in the daemon on known-fatal socket errors.

Pretty sure that if sendall() doesn't abstract such errors away on windows, it's a bug in the interpreter itself, but feel free to correct me here, I haven't ran much socket-related python code there.

* Close socket on errors in gobject path, just as it's done in select.

Before this, all socket errors in send() are effectively hidden from the higher-level code, which, to be honest, looks like a crime against nature, a thing that's done in e.g. php.

Such hiding immediately results in daemon only able to handle a single connection (and hang foreverafter) and potentially means that any unexpected error is hidden, resulting in potential data loss or any sort of insane behavior propagnating up from there.

* For whatever reason, (quite pointless) tls negotiation fails 1/4 times here, resulting in unhandled error, which (again, thanks to whoever thought of using threads is Skype4Py) hangs the daemon.

TLS errors here are subject of a different issue, as currently any network issue during (or tampering with-) handshake will result in permanent DoS on skyped end, which seem to be quite unfortunate.