curl-library
question about curl_multi_perform, callbacks, and presenting a pull interface
Date: Thu, 23 Aug 2012 12:14:35 -0400
Hi,
I am trying to present a blocking, pull interface to a client using
curl internally (this interface is already implemented using WinHTTP
on Windows and I would like to port it to Linux and OSX using curl as
the internal HTTP engine). The a simplified portion of the interface
looks something like:
int Get(url);
size_t Read(char* buffer, size_t length);
The user calls Get() which will return the response code and can then
optionally call Read() until it returns 0. This allows the client to
read as much/little and at what rate suits them.
Under the covers I use a multihandle and curl_multi_perform. When I
originally designed this I assumed that a curl_multi_perform would
invoke either 0 or 1 of my write callbacks. Testing seems to indicate
this is not necessarily the case.
Question 1: Can a single call to curl_multi_perform result in
multiple write callbacks?
Internally my library wrapper keeps a fixed-buffer of size
CURL_MAX_WRITE_SIZE of the data provided by curl calling the write
callback. Assuming a 1-1 perform/callback the flow would go:
1) Caller invokes Read()
2) If my lib has data buffered, copy data to caller buffer and return
bytes copied otherwise call curl_multi_perform()
3) If no data from curl, select and loop until data (client is blocked
on Read())
4) If callback was invoked, copy data from library buffer to caller
buffer and return bytes copied
The problem I have with this, is if the write callback is invoked
multiple times before an intervening caller Read() drains the
libraries internal buffer, data is lost (overwritten in my libraries
internal buffer).
Question 2: Are all my observations correct up to this point?
Question 3: What is the best way to craft an interface like this using
curl? Can I use curl_easy_pause() after each write callback and then
unpause after the client drains my internal buffer and my library
needs more data from curl?
I figured I would ask for some pointers or guidance before pursuing
any additional lines of research.
Thank you.
Rich
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-08-23