On Wed, Aug 11, 2010 at 3:14 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Tue, 10 Aug 2010, Jogeshwar Karthik Akundi wrote:
>
> Write shouldn't block. I give data to write, CURL would give a
>> writeComplete_callback later that write is complete.
>> Read shouldn't block. I should get a data_callback whenever data is
>> received
>> on socket.
>>
>
> That's not really how it works in anything but Windows perhaps[*].
>
> IO in Linux and unix is generally non-blocking not asynchronous, so you do
> as much as possible immediately without blocking, and then you wait for the
> socket to have more data or be prepared to get more data.
>
> If you truly want "asynchronous", you build it with threads but the
> underlying fundamentals are still "just" non-blocking and libcurl provides
> such non-blocking fundamentals just fine.
>
> I'll second Frank's question: what exactly are you planning to do that the
> normal multi interface can't do for you?
>

We use libCURL only to do https and to handle proxies. After the connection,
it is all our custom data sent directly on socket. So, we use
CURLOPT_CONNECT_ONLY option.
My application is mainly about sending lot of data to server. But I also
need to be reading some stuff which server keeps sending to me. Main problem
here is that I cannot do a read while I am writing. If the socket is in a
writable state AND I give a chunk of data to CURL, write blocks till the
data gets written. As my application is really write-intensive, the reads
are coming in very delayed. CURL is non-blocking but I am looking for
asynchronous framework to do reads/writes in parallel (like ACE library- if
I understand it correct, ACE is a true asynchronous framework).
Also, the same codebase has to run on Windows/Linux/Mac. So prefer to stick
to libCURL.

>
> If you're looking for high performance socket and event handling on *nix,
> the answer is rather called libev or libevent rather than anything else - in
> combination with libcurl's event-based API multi_socket.
>
> [*] = stuff like SIGIO/SIGPOLL exists, but its not really what anyone uses
> and it has significant drawbacks anyway.
>
> --
>
> / daniel.haxx.se
>
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html
>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-08-11