Daniel Stenberg wrote:
On Tue, 7 Jul 2009, Mohun Biswas wrote:
Just use it as documented and that's how it'll work.
Now why didn't I think of that?? :-<
Seriously, I'm trying to say that the documentation is not
sufficiently clear but you apparently do not agree so I'll continue
trying to puzzle through it.
Well, you expressed a fear of a certain functionality that was unfounded
I'd say and certainly was not implied in the documentation - the sockets
will not be ready at all times. So libcurl will not accidentally "lock"
you in a synchronous manner because of that.
So what exactly is the question/problem again?
I'd say the meta-problem is precisely due to the deliberately vague
phrasing. I understand the value of leaving certain things unspecified,
but there's such a thing as being too imprecise. The point of any
high-level API is to insulate users from low-level details; I shouldn't
have to know assembly language to use gcc, I shouldn't have to know
POSIX threads in order to use Java threads, and (IMHO) I shouldn't have
to be a socket guru in order to use libcurl. Unfortunately, the vague
phrasing means we have to know what sockets are open along with their
current state and semantics.
For instance, even a non-expert like me knows that in order to transfer
a file from here to there we need two file descriptors: one from which
to read the file and one to write to. The libcurl-multi document makes
no distinction between the two, which I guess is because you assume we
understand that one is a socket which can block and the other is likely
to be a file which will not.
The libcurl-multi doc says things like "libcurl will then transfer data
if there is anything available to transfer". Since I'm doing uploads I
read this, as I think any native speaker of English would, to mean "if
there's anything ready *on the input side*". I'm guessing you really
mean "libcurl will then transfer data if any socket is ready". Or maybe
even "... if doing so would not cause the program to sleep". Or
something - since I don't actually _know_ what it does, it's hard to
suggest language.
Next, wrt CURLM_CALL_MULTI_PERFORM you might want to be more clear in
saying "you probably don't want to do anything which would cause your
program to block while curl_multi_perform still has data ready to
transfer". You state it in terms of select() but there are more ways to
block and that - you could wait for a child, for instance. Again, this
assumes I now understand it.
Here's another thing I don't know about sockets: is there any
correlation between a socket being "ready" and the speed of the physical
connection? What I'm afraid of is that a socket on a slow connection
will continually signal ready. If I need to send a large file to it, it
seems to me I could still be tied up for a very long time sending data
there because the socket might remain ready even though the connection
is slow. But maybe I misunderstand and the socket will become unready
until its buffers are drained? This is the sort of low-level detail that
I think should either be handled internally by an API or spelled out in
its documentation.
As before, I'm happy to help with the wording once I understand it well
enough to contribute.
Thanks,
MB
