On Sun, 4 May 2008, tetetest tetetest wrote:

> Well, if we mimick the send()/recv() behaviour, then it is logical not only
> to return an equivalent of EAGAIN, but also to provide something analogous
> to select().

I disagree. First, send() is separate from select() so mimicing send() does
not imply select().

Then, select(), poll(), epoll() and similar functions should all still be
possible to use and thus it would be pointless for us to offer a function with
the exact same funtion and purpose.

curl_easy_send() and curl_easy_recv() would be provided because they cannot by
done otherwise.

And in fact, the EAGAIN functionality of send() and recv() is something that
is appreciated and used by apps, and I therefore think not offering it will
surprise authors and thus cause errors and confusions.

> Otherwise the application is forced to use "split interface": sending and
> receiving data is done using fairly abstract functions, but to make sure you
> can use these functions you should get the underlying socket and wait on it.

Applications will need to "split interface" yes, but as long as we document
how I don't see why that is a problem. We can't possibly try to implement and
offer every useful select() or poll() version.

libcurl already offers this "split interface" approach for the multi
interface, and I would even claim that it is quite common practise for
libraries of libcurl's kind.

>> So, supporting an EAGAIN-style return code will make our functions more
>> likely to work as drop-in replacements in existing applications.
>
> In essence this means that we add at least one more CURLE_* error code.

Yes, I can't think of any better way.

> Besides, Curl_write() should be modified to take into account this error:
> currently it returns CURLE_SEND_ERROR if the socket is not ready.

Nope it doesn't. It returns 0 bytes written and CURLE_OK.

But yes, of course the underlying code would need to do right.

> Three more files modified.

I really don't care if we end up modifying a hundred files. I do think it is
worth spending extra time, effort and thoughts on making new functions work
nicely and I rather patch extra files to get the API done nicely than the
opposite.

It will be me, not you, who will hang around and support this and answer
questions and track down subtle bugs in the distant future. This is not a
personal thing against you, just my experience saying that it always happen
eventually and if I don't make an effort to make things right in new functions
from the start, we will suffer in the future and get great pains when we need
to change the API and the soname number will change and 42 linux distros come
running after me with pitchforks. (possibly not literally :-)

> So I propose to state a clear distinction between curl_easy_{send|recv} and
> system functions: they are similar, but still they are different and cannot
> be substituted with one another. To make this distinction even clearer, and
> to fully abstract the user from system sockets, I propose to introduce some
> analogue of 'select()' that will return the status of a CURL* handle.

I disagree. I think we should make curl_easy_send() and curl_easy_recv() as
good and useful as possible, and we should document how they can/should be
used together with select()/poll()/whatever to cause the least amount of
grief. I think offering EAGAIN functionality is just a matter of making them
even more useful.

I've personally never seen a library offer a good select() version and I even
consider just the attempt futile and doomed to not be good enough. That's also
why libcurl doesn't already have a select()-style function now, and why you'll
have a very hard time to convince me that we need to add one.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html