UDP sockets create infinite read events if no task is reading

[korobochka]

Hello,
I have an UDP socket for receiving broadcasts and a task that calls socket.recv.
After calling task.interrupt from other task my receiving task stops (gracefully, InterruptException is handled) which results in an infinite amounts of read events on socket, CPU is at 100%.
Trace log contains 100 MB of this(after running for 5 seconds at most):

[024D0F80:00000000 2014.07.08 15:18:07.971 trc] udp socket 348 read event!
[024D0F80:00000000 2014.07.08 15:18:07.971 trc] udp socket 348 read event!
[024D0F80:00000000 2014.07.08 15:18:07.971 trc] udp socket 348 read event!
[024D0F80:00000000 2014.07.08 15:18:07.971 trc] udp socket 348 read event!

Is it my fault for not "closing" socket properly or is it a bug?

[s-ludwig]

Related: #695
Currently libevent will call the event handler in every event loop iteration until the socket doesn't have data to read anymore instead of only once. This can probably be fixed by simply setting the underlying libevent object to edge triggered mode, but that needs some careful testing to ensure that this doesn't produce any hangs due to lost events.

[korobochka]

Also about UDP sockets:

• is there a way to close UDP socket now?
• after creating UDP socket with port 0 (OS decides which port to use) is there a way to get the actual port assigned to the socket? socket.address.port remains 0.

[s-ludwig]

I've added UDPConnection.close() and fixed how the actual bind address is determined. It's still more or less untested right now, though.