Hi Jameson, This is regarding PR, If we have a close the poll_handle, will it close the poll handle and call the close_cb immediately? This way as we send a single message over a socket at a time, i could close and recreate a new handle for the new message.
Please let me know if my understanding of PR is correct. Also do let me know when the PR gets into libuv main stream? Thanks, Srikanth On Saturday, 13 May 2017 01:47:39 UTC+5:30, Jameson Nash wrote: > > 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] <javascript:>> 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] <javascript:>. >> To post to this group, send email to [email protected] <javascript:> >> . >> 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.
