[prev in list] [next in list] [prev in thread] [next in thread] 

List:       curl-users
Subject:    Re: Birthday Gift?
From:       "Daniel Stenberg" <Daniel.Stenberg () haxx ! se>
Date:       1999-11-15 23:04:38
[Download RAW message or body]


On 15 Nov 1999, Thomas Hurst wrote:

> I would... at least until cURL will retry a failed download massively...

In good old unix fashion one tool does one tool's task. Curl does its task,
nothing else. Mostly.

Making a shell-script that makes curl retry is done with two three lines.

> by default, dumping to stdout suggest to me cURL's more a tool in crons,
> or on command lines to pipe to other programs.

Allow me to quote from a book I have, named The UNIX Philosophy:

  "Tenet 9: Make Every Program A Filter"

of course it sends its data to stdout. That's what unix programs do. That's
to enable fancy scripting, filtering, piping and all those nifty things unix
do that well that we love.

> > I've never heard of it before. I would believe this is amiga specific,
> > yes. Could you bring us some more details about this?
> 
> During a http download, my modem dropped. cURL then proceeded to leech
> all my CPU in writing null bytes to the output file. Presumably it's a
> problem checking the return value of recv().

To start with, it isn't a recv() call at all. It is a read(). If amiga wants
a recv() there, it sure explains this problem.

Since I have never before got this reported, on any platform, it makes me do
assumptions. One of those are that this might be a system-specific problem. I
don't have any evidence of that yet, though.

It shouldn't even reach the read() if the connection is dropped. The select()
should in that case return -1 for error and the loop should get aborted right
away (and if the abort was made with data in the socket, it should return
that fd and then the read() should be able to read the amount of data
available). The one and only read() is done on line 174 in download.c and the
return code is checked at line 189. read() is named sread() in the source
code to hide the fact that wi32 uses a different function call.

> I'll have a look at the src and see if I can see anything, but I suck, so
> don't expect much :)

I'm afraid I can't be of much assistance either until I can get my hands on a
system that can repeat this behaviour. :-(


-- 
            Daniel Stenberg -- http://www.haxx.se 
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol

[prev in list] [next in list] [prev in thread] [next in thread]