New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UDP sockets create infinite read events if no task is reading #715

Closed
korobochka opened this Issue Jul 8, 2014 · 3 comments

Comments

Projects
None yet
2 participants
@korobochka

korobochka commented Jul 8, 2014

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

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Jul 9, 2014

Member

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.

Member

s-ludwig commented Jul 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@korobochka

korobochka Jul 11, 2014

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.

korobochka commented Jul 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Jul 12, 2014

Member

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

Member

s-ludwig commented Jul 12, 2014

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

@s-ludwig s-ludwig closed this in d5593cb Jul 12, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment