Thanks for your quick reply. Actually I implement my own WebRTC ICE stack(I think you know what I mean :) ), and I create one event loop for each udp handle . Because loop would block the main thread , I also create one thread for each loop (I have no idea if I use the loop in the right way). So uv_udp_try_send is called in the other thread.
在 2018年10月25日星期四 UTC+8下午6:07:13，Saúl Ibarra Corretgé写道： > > > > > On Oct 25, 2018, at 10:10, Chen Cong <[email protected] <javascript:>> > wrote: > > > > Hi, > > > > I use libuv to build a high throughput udp server , and I have some > questions about libuv. > > > > 1. using "uv_udp_send" or "uv_udp_try_send" ? I use "uv_udp_try_send" > now , and it seems that "uv_udp_try_send" is thread-safe. > > > > It’s not. Even if it may coincidentally be, that’s en implementation > detail. All APIs are thread-UNsafe unsafe unless stated otherwise. > > > 2. if "uv_udp_try_send" is better , how can I use it to send packet ? I > know "uv_udp_try_send" is not thread-safe, and I find a related thread. I > want to know if PC-capable pipe server is still a good way to solve this > situation. > > > > I don’t understand the question. One is not better than the other, they > server different purposes. uv_udp_try_send will not queue data so you can > call it with a stack allocated buffer for example. When using uv_udp_send, > the request needs to “survive” until the callback is called. > > The typical use case is to try to send the packet with try_send, and if it > doesn’t succeed, send it with the regular send. > > I don’t understand why you mix threads with these APIs. > > > Cheers, > > -- > Saúl > > -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
