On Fri, 9 Aug 2013, Bill Doyle wrote:

>> It is always one single (active) timer and it is always single-shot
>
> Alright, cool. This makes it a bit more complicated, as there's no way to
> cancel a dispatch_after() call to change an existing timeout. Will I run
> into issues if I leave the previous timeout running after creating a new
> one? It would cause an extra call to curl_multi_socket_action()

While I think that's a rather sever limitation of a timer functionality,
calling curl_multi_socket_action() a little bit too often won't cause any harm
at all. It'll just not be as optimal as otherwise.

> I'm already seeing. I'm using the default resolver, and it doesn't
> seem to set a timeout, or if it does, it's not doing it through my
> TIMEOUTFUNCTION. This leads me into the new discoveries that I've
> made.

The default name resolver is synchronous so it'll block until done so it
doesn't use a timer.

> I fixed the odd looking log output.

Great, removing doubts and problems one by one is indeed good and will help us
to eventually get down to the actual culprit!

> Secondly, and more importantly, I discovered that it isn't outright hanging
> after dropping the control connection. I ran out of ideas and decided to let
> it just sit there after running as far as it usually does, and, lo and
> behold, it 15 minutes later it finally timed out with code 55! Before
> stopping, it printed "150 Data Connection Accepted", meaning that it must
> have received that from the server prior to hanging. The fact that it didn't
> print it out prior to this makes me think that maybe that message was stuck
> in the socket somehow, and my dispatch queue sources didn't pick it up?

A very strange effect. I won't rule out the risk that this is actually a
libcurl bug so that perhaps you've not been told to wait for the correct
socket action and the 15 minutes timeout that occurs is probably something the
server end has implemented...

I'll see if I can get some time soon to write an event-based ftp upload
application in plain C with something like libevent and verify how that works.
Unfortunately we don't have any event-based tests in the test suite. I have
that on my TODO for the coming months but I can't promise anything. (And I'll
bring this up in a separate topic on the list in a short while.)

> In addition, it called the read_function twice or so (probably just
> from the false action on the socket being picked up?), print a bit of
> what I assume was the contents of the test file (a jpeg, so it was
> nonsense), and then finally let me know that it "timed out after x
> milliseconds with 0 out of -1 bytes received". A fifteen minute
> timeout was never set using my timeout_callback, so where is this
> occuring? Is it within libcurl, or is this some system thing giving up
> and forcing the socket closed?

From what I can tell, those outputs are all shown when libcurl considers a
timeout to have expired. (They exist in two places in the code.)

> This last part also makes me curious: It appears that it's letting me know
> that it *downloaded* 0 out of -1 bytes, which makes sense, being an upload.

I believe that's just a flaw in the output message. It shows that completely
unconditionally of what operation that was attempted. We can consider that
room for improvement!

> Finally, I'm seeing a very odd and extremely intermittent issue: every once
> in a while, when I perform the upload (with no variation in the process, at
> least that *I'm* causing), rather than just getting the normal messages
> about reading on a socket, I see a massive amount of writes.

Are those happening when libcurl has told the app to wait for a socket
writability and the socket turns writable? Or who's telling that socket write
thing? It seems wrong to wait for a writable socket when libcurl waits for a
command response...

There's a chance that the problems you see and have are depending on timing so
perhaps every once in a while it'll act different due to the timing and things
happening slighlty slower or faster or in another order...

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html