According to http://docs.libuv.org/en/v1.x/poll.html, "It is not okay to have multiple active poll handles for the same socket, this can cause libuv to busyloop or otherwise malfunction.:
Although there is the PR against the issue I linked to fix one issue in this area, as it should be valid to reuse the handle immediately after closing it. On Fri, May 12, 2017 at 4:14 PM Srinivasa Srikanth Podila < [email protected]> wrote: > Hi Jameson, > > I did it out of my ignorance as i am new to google groups and libuv group > as well. Sorry for inconvenience caused. > Thank you very much for your replies. > > Could you please let me know if there is any active development going in > libuv to support multiple handles against same fd? > > Thanks, > Srikanth > > On Saturday, 13 May 2017 01:25:44 UTC+5:30, Jameson Nash wrote: > >> Please don't PM me questions. I am not your support, and it is improper >> etiquette to take discussions off list. >> >> libuv doesn't not permit multiple handles to exist against the same fd. >> >> `uv_poll_stop` doesn't release the libuv resources either. But it does >> give you a good, safe place to call uv_close from (although uv_close also >> calls uv_poll_stop, so the extra step isn't really necessary). However, >> according to bug https://github.com/libuv/libuv/issues/1148, it looks >> like you'll also need to wait for `uv_close` notification to complete >> before reusing the fd. >> >> >> On Fri, May 12, 2017 at 3:25 PM srinivasa srikanth podila < >> [email protected]> wrote: >> > Hi Jameson, >>> >>> Consider a scenario i have a socket connection and i send continuous >>> HTTP GET requests for different URL's asynchronously on the same socket. I >>> shall be creating multiple poll handles for each request rite. why is this >>> scenario of multiple poll-handles[allocated separately] on socket not >>> supported by libuv? >>> >>> uv_poll_stop does not give me a callback context to free the alloc'd >>> memory. so i have only option of uv_close. >>> >>> Srikanth >>> >>> On Fri, 12 May 2017 at 23:38 Jameson Nash <[email protected]> wrote: >>> >> It is possible. You do have to be careful not to have multiple active at >>>> the same time though (`uv_poll_stop` can help with this. I've found it can >>>> be helpful to call that from the poll callback, as that can enable libuv to >>>> avoid re-adding it to the event list.) >>>> >>>> >>>> On Fri, May 12, 2017 at 1:47 PM Srinivasa Srikanth Podila < >>>> [email protected]> wrote: >>>> >>>>> Thanks for your reply. >>>>> >>>>> I am using multiple poll-handles on same sockfd's. However the >>>>> poll-handles are from different requests. It is like sending multiple HTTP >>>>> gets on same socket. >>>>> Please let me know if any problem with libuv to handle this. >>>>> >>>>> Could you please clarify this? >>>>> >>>>> Thanks, >>>>> Srikanth >>>>> >>>>> On Friday, 12 May 2017 22:57:08 UTC+5:30, Jameson Nash wrote: >>>>>> >>>>>> You might want to try running under rr (record and replay) to find >>>>>> out where the memory usage is diverging from your expectations. >>>>>> >>>>>> On Fri, May 12, 2017 at 11:21 AM Srinivasa Srikanth Podila < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Update: I am using multiple poll-handles on same sockfd's. However >>>>>>> the poll-handles are from different requests. It is like sending >>>>>>> multiple >>>>>>> HTTP gets on same socket. >>>>>>> Please let me know if any problem with libuv to handle this. >>>>>>> >>>>>>> >>>>>>> On Friday, 12 May 2017 19:11:48 UTC+5:30, Srinivasa Srikanth Podila >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I am allocating memory for a struct "request" using malloc. The >>>>>>>> request object has a uv_poll_handle as a member. >>>>>>>> >>>>>>>> The request updates its poll_handle on a sockfd *[using >>>>>>>> uv_poll_init_socket(loop, &request->poll_handle, sockfd)] *received >>>>>>>> by libcurl. After init_socket, i update poll_handle.data to "request" >>>>>>>> object so that i could use in uv callback context, and starts polling >>>>>>>> on it >>>>>>>> using* [uv_poll_start(&request->poll_handle, events, >>>>>>>> poll_req_uv_cb);]* >>>>>>>> >>>>>>>> Now when i get poll_remove notification from libcurl, I am using >>>>>>>> *[uv_close((uv_handle_t >>>>>>>> *)&request->poll_handle, process_request_response)]. *The >>>>>>>> process_request_response is close_callback which i am planning to free >>>>>>>> the >>>>>>>> allocated "request" object. >>>>>>>> >>>>>>>> I do it for many request objects in a default-loop continuously. It >>>>>>>> works fine for some time and after some time, i see the SIGSEGV as >>>>>>>> poll_handle.data is NULL and loop object also NULL in the close >>>>>>>> callback api >>>>>>>> *[process_request_response]*. >>>>>>>> >>>>>>>> Please check the inline gdb logs. >>>>>>>> >>>>>>>> (gdb) p req >>>>>>>> $1 = (uv_handle_t *) 0xe159b0 >>>>>>>> (gdb) p *req >>>>>>>> $2 = {*data = 0x0, loop = 0x0*, type = UV_POLL, close_cb = >>>>>>>> 0x404b5d <process_request_response>, handle_queue = {0xe09760, >>>>>>>> 0x62e6a0}, u >>>>>>>> = {fd = 0, reserved = {0x0, 0x0, 0x0, >>>>>>>> 0x0}}, next_closing = 0xe09740, flags = 3} >>>>>>>> >>>>>>>> Just before i close the uv_poll_handle, I have a print to ensure if >>>>>>>> i have the data. >>>>>>>> INFO, 12:54:31.266583, curl_socket_cb, STOP POLL Curl >>>>>>>> Handle:0xeb26c0, Request:0xe159a0, poll_handle:0xe159b0 >>>>>>>> poll_request:0xe159a0 >>>>>>>> >>>>>>>> Please let me know if there is any problem in my design approach >>>>>>>> (or) let me know if there is any bug in this area. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Srikanth >>>>>>>> >>>>>>> -- >>>>>>> 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. >>>>>>> >>>>>> -- > 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. > -- 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.
