Non-blocking sockets and blocking sockets with a timeout do not work correctly when using WinSock backend

[GoogleCodeExporter]

Calling BluetoothSocket.settimeout(t) with t > 0 on Windows using the WinSock 
Bluetooth stack does not correctly emulate the behaviour of socket.socket; 
instead it simply forces it to be blocking with no timeout.  A related problem 
is also present in non-blocking sockets because PyBluez explicitly does not 
throw exceptions from operations that have either timed out or that would have 
blocked.

This makes it impossible to determine the reason for the socket returning null 
data as it may have done so due a timeout, no data in the buffer or a client 
disconnection.

I have modified the msbt.py and _msbt.c files to resolve both issues and have 
attached a unified diff for each file.  In brief, I modified the settimeout 
function in msbt.py to prevent it from setting the timeout to 0, and then 
modified the msbt_send and msbt_recv functions in _msbt.c to throw an IOError 
exception if the operation would block (i.e. no data in the buffer) or if it 
has timed out.  This is not quite the same as the behaviour of socket.socket 
but it is close enough because socket.error and socket.timeout appear to be 
derived from IOError.

Original issue reported on code.google.com by [email protected] on 28 Jan 2011 at 8:55

Attachments:

• msbt.py.diff
• _msbt.c.diff

[GoogleCodeExporter]

I tried commenting out the line 'timeout=0' in 'msbt.py' but 'accept()' still 
goes into blocking state with no timeout. Is there something that I am doing 
wrong??

OS - WIN7 SP1
Python - 2.7.5
Pybluez - 0.20

Original comment by [email protected] on 11 Oct 2014 at 9:28