How long does uv_write_t need to stay in memory vs a uv_connect_t?

[Ryan Hanson]

Hello I have just started implementing some examples I have found. I notice on a uv_tcp_connect callback that I create a uv_write_t object on the stack and use that to call uv_write. Do I need to be careful with that uv_write_t object if the connect callback leaves scope? Or are all request callback executed in the request function call? How about uv_connect_t? The uv_connect_t objects seem like they need to last a while.

Thanks

[Saúl Ibarra Corretgé]

> On Feb 5, 2018, at 00:17, Ryan Hanson <hans...@gmail.com> wrote:
>
> Hello I have just started implementing some examples I have found. I notice on a uv_tcp_connect callback that I create a uv_write_t object on the stack and use that to call uv_write. Do I need to be careful with that uv_write_t object if the connect callback leaves scope? Or are all request callback executed in the request function call? How about uv_connect_t? The uv_connect_t objects seem like they need to last a while.
>

uv_write cannot be allocated on the stack because it will be used / tracked by the loop until its callback is called. You can use uv_try_write to try an inline write, and if you fail, allocate a uv_write request on the heap and trigger it again.

As a general rule of thumb, all requests are used by the bridge until their completion callback is called.


Cheers,

> Thanks
>
> --
> 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 libuv+un...@googlegroups.com.
> To post to this group, send email to li...@googlegroups.com.
> Visit this group at https://groups.google.com/group/libuv.
> For more options, visit https://groups.google.com/d/optout.

--
Saúl

[Ryan Hanson]

Thanks! That actually solved an issue I had with the loop locking up.