net: Add UdpSocket::{try_send,try_send_to} methods

[kleimkuhler]

Motivation

It is currently not possible send data on a single UdpSocket from multiple
locations because the send methods take &mut self. This change introduces
try_send methods that take &self.

Solution

Closes #1624

The &mut self requirements on send and send_to are enforced so that one
task cannot deadlock another.

If two tasks concurrently register interest in sending data and immediately
sending data would block, one task will overwrite the other's interest. This
will cause the task that "won" the race in registering to deadlock. While this
is an uncommon case, it introduces the possibility of it happening and should be
avoided.

The new try_send and try_send_to methods take &self and sidestep the above
issue by not registering the tasks interest. try_send immediately returns
the number of bytes sent or an error if one occurred. try_send_to first
resolves the given target to a SocketAddr, and then immediately tries sending
the data.

try_recv and try_recv_from

These methods would be equivalent to what is being introduced in this change,
but for receving data on a UdpSocket. This is a less common case, but if it
makes sense to include them in this PR then I can add them.

Signed-off-by: Kevin Leimkuhler kleimkuhler@icloud.com

[kleimkuhler]

Hm this seems a little tricky due to Mio's UdpSocket::{send,recv} methods in v0.6.x.

Before checking if data can even be sent, the binding status of the source is expected to have been registered

This has been changed in v0.7.x and will not be an issue.. Need to figure out what makes sense for this while still on 0.6.

[carllerche]

Don’t we register in inititialization?

…

On Tue, Dec 17, 2019 at 4:58 PM Kevin Leimkuhler ***@***.***> wrote: Hm this seems a little tricky due to Mio's UdpSocket::{send,recv} methods in v0.6.x <https://github.com/tokio-rs/mio/blob/8078b9034dfbe4e93277877a34ea803b55c7e3a9/src/sys/windows/udp.rs#L90-L91> . Before checking if data can even be sent, the binding status of the source is expected to have been registered <https://github.com/tokio-rs/mio/blob/8078b9034dfbe4e93277877a34ea803b55c7e3a9/src/sys/windows/udp.rs#L100> This has been changed in v0.7.x and will not be an issue.. Need to figure out what makes sense for this while still on 0.6. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1979?email_source=notifications&email_token=AAABQJGGDF3VOMMHCHLR6KTQZFYSZA5CNFSM4J4DAL52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHEPN5A#issuecomment-566818548>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABQJDDATJGSEKRU5BMX4DQZFYSZANCNFSM4J4DAL5Q> .

[kleimkuhler]

@carllerche Registration only happens during the first poll_write_ready/poll_read_ready. This is true for Unix as well, however Mio 0.6 does not require Unix resources to be registered when trying to send or receive data.

Edit: This was incorrect. This commet resolves the issue.

[carllerche]

@kleimkuhler can we change that to register earlier? Maybe in try_send if needed?

[kleimkuhler]

@carllerche The issue was not registration. I restrucuted the test to work
cross-platform and left the note below on the test.

This test is purposely written such that each time sender sends data on
the socket, receiver awaits the data. On Unix, it would be okay waiting
until the end of the test to receive all the data. On Windows, this would
not be okay because it's resources are completion based (via IOCP). If
data is sent and not yet received, attempting to send more data will result
in ErrorKind::WouldBlock until the first operation completes.

[Mygod]

I am not completely sure what the issue is but it seems like it is because mio does not track how many tasks are concurrently expressing interest for the same object?