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] <javascript:>> 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] <javascript:>> >> 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] <javascript:>> 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.
