> > > > > On Friday, 24 March 2017 13:23:33 UTC, Ben Noordhuis wrote: > > > > On Thu, Mar 23, 2017 at 8:24 PM, doa379 <[email protected] > > <javascript:>> wrote: > > > I'm trying to integrate libuv with libcurl. > > > The uv_poll_start function uses the callback function curl_perform > > whenever > > > (action) events call for polling IN and OUT like so: > > > > > > switch (action) > > > { > > > case CURL_POLL_INOUT: > > > uv_poll_start(&curl_context->poll_handle, events, > curl_perform); > > > break; > > > } > > > > > > Is it possible to use a different callback function or pass > > additional > > > parameters to it? > > > > You can set curl_context->poll_handle.data to a pointer or use a > > container_of-like macro to obtain the enclosing curl_context in your > > uv_poll_cb callback. > > > > > > The prototype of the uv_poll_cb function is: > > > > void |(*uv_poll_cb)|(uv_poll_t > > <http://docs.libuv.org/en/v1.x/poll.html#c.uv_poll_t>*/ handle/, > > int/ status/, int/ events/) > > > > If one sends a generic structure (encapsulating the poll_handle) there's > > no void * arguments in the uv_poll_cb which one could de-reference. > > > > Not sure I follow. You have a reference to the handle itself, so you > could get a pointer to the enclosing structure, or use handle->data, > which is a void* for you to use. > > > The specific problem in my case is I want to pass a CURLM handle (which > > happens to be nested away in some other struct) to the uv_poll_cb > > function which in this case is called curl_perform. This entire exercise > > is following the multi-uv.c example here: > > > > https://curl.haxx.se/libcurl/c/multi-uv.html > > > > As an aside I'm not entirely sure if it's worth considering a more > > flexible callback function in the API. > > > > So far nobody has requested this, what do you have in mind? > >
This seems fine. Thanks for pointing this out in the API. Are there any further examples of libuv usage with libcurl? I've set all the callbacks up and the pointers are correctly carried through the various but by the time the program reaches the end stage the resulting operation happens incorrectly. The program just hogs the cpu timeslices, and nor does it quit. There are no segfaults. The memory addresses and pass-throughs appear correct as I've also checked them by hand. It would seem that something erroneous happens to the CURLM * handle by the end. Although the memory address of the CURLM * handle is correct. -- 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.
