Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
libcurl socket interface and timeout (ephiperfifo example)
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Nicolas Martin via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 23 Jun 2025 09:50:26 +0200
Hello everyone,
I'm writing an application that receives HTTP Server-Sent Events and also
listens to non-HTTP sockets.
I chose to use libcurl socket interface.
I've been studying the example ephiperfifo to understand how to use the
interface.
https://curl.se/libcurl/c/ephiperfifo.html
I want to make sure I got it right, and also avoid using unneeded code for
my application.
Could someone help me confirm/correct my understanding of the following:
1- multi_timer_cb
It's an optimization so libcurl will ask to timeout sooner and data will be
read/written without waiting for a full timeout.
In the case of SSE, we don't really know when the server will send us
messages. In practice, I noticed that once the initial subscribe to the
server events is done, libcurl asks for the timer to be removed (timeout
parameter set to -1).
So in my application, it's OK not to use this timer.
2- timer_cb
I don't understand the need to set this timer. If epoll exits with code 0,
that means a timeout has passed and we can call
curl_multi_socket_action(CURL_SOCKET_TIMEOUT). Why use a timerfd for this ?
3- knowing which fd belongs to curl
Once epoll exits, and events are received, I need to know which fds belongs
to curl and which fds belong to my non-HTTP sockets, so I can call
curl_multi_socket_action or a function to process the non-HTTP data.
I thought about passing a private data pointer to epoll_ctl when I add the
fds (containing a type to discriminate against); another way would be to
save somewhere the fds when the sock_cb callback is ran by libcurl, so I
know which fds belong to libcurl.
But I'm wondering if there is an existing function in libcurl that is able
to say if a file descriptor belongs to libcurl or not ?
Thanks a lot for your help,
Nicolas Martin
Date: Mon, 23 Jun 2025 09:50:26 +0200
Hello everyone,
I'm writing an application that receives HTTP Server-Sent Events and also
listens to non-HTTP sockets.
I chose to use libcurl socket interface.
I've been studying the example ephiperfifo to understand how to use the
interface.
https://curl.se/libcurl/c/ephiperfifo.html
I want to make sure I got it right, and also avoid using unneeded code for
my application.
Could someone help me confirm/correct my understanding of the following:
1- multi_timer_cb
It's an optimization so libcurl will ask to timeout sooner and data will be
read/written without waiting for a full timeout.
In the case of SSE, we don't really know when the server will send us
messages. In practice, I noticed that once the initial subscribe to the
server events is done, libcurl asks for the timer to be removed (timeout
parameter set to -1).
So in my application, it's OK not to use this timer.
2- timer_cb
I don't understand the need to set this timer. If epoll exits with code 0,
that means a timeout has passed and we can call
curl_multi_socket_action(CURL_SOCKET_TIMEOUT). Why use a timerfd for this ?
3- knowing which fd belongs to curl
Once epoll exits, and events are received, I need to know which fds belongs
to curl and which fds belong to my non-HTTP sockets, so I can call
curl_multi_socket_action or a function to process the non-HTTP data.
I thought about passing a private data pointer to epoll_ctl when I add the
fds (containing a type to discriminate against); another way would be to
save somewhere the fds when the sock_cb callback is ran by libcurl, so I
know which fds belong to libcurl.
But I'm wondering if there is an existing function in libcurl that is able
to say if a file descriptor belongs to libcurl or not ?
Thanks a lot for your help,
Nicolas Martin
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-06-23