* Daniel Stenberg <daniel_at_haxx.se> [Sat, 3 May 2008 13:54:01 +0200
(CEST)]:

> But why enforce this rule when there's really no reason? I think
people
> using them will appreciate that these functions work like send() and
> recv() and those functions (the plain send/recv I mean) can be called
> in (possibly) blocking situations and the return code tells what
> happened. Returning the standard recv or send error in that situation
> is not right in any case IMHO.

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(). 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.

For me, using OS-provided select() and poll() is a nightmare: I always
forget how the arguments are to be provided and results checked, so I
have to study the same man pages again and again. Adding an abstract
status-checking function with simplified interface will be appreciated
(at least by me). :)

> 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.
Besides, Curl_write() should be modified to take into account this
error: currently it returns CURLE_SEND_ERROR if the socket is not ready.
Three more files modified.

Considering drop-in replacement in existing applications: personally, I
don't think it is a good idea to offer such functionality. Yes,
curl_easy_{send|recv} are somewhat similar to send()/recv(); but they
are not at all analogous! Even sockets returned by CURLINFO_LASTSOCKET
cannot be freely used in a custom socket engine (libcurl caches sockets
internally which can affect the behaviour of such engines; libcurl makes
sockets non-blocking, etc). I am sure that there are lots of weird
usages of sockets out there, all of them incompatible with libcurl; no
need to take additional burden of supporting such usages.

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. Something like this:

typedef enum {
  CURLDIR_IN, /* can safely call curl_easy_recv() */
  CURLDIR_OUT /* can safely call curl_easy_send() */
} CURLdirection;

/* returns true if the handle can be read from or written to;
   returns false in case of timeout */
bool curl_easy_poll(CURL *curl, CURLdirection d, double timeout_in_sec);

What do you think?

--
tetetest tetetest.