On Tue, 24 Oct 2000, Georg Horn wrote:

> thanks to Daniel for the hint with freshmeat, i'll do further work on the
> perl-interface if time permits

Spreading the news about the perl-interface will get more users, and most
likely more curl users. Having more users will improve the program.

> (and if the lowlevel interface of libcurl is ready, *hehe* ;-))

Don't hold your breath for this. The lowlevel interface is more of a dream
and concept than reality.

> Currently i have another problem: Sometimes when fetching a page from a heavy
> loaded server, there happens a timeout during connecting to the server.

The timeout stuff is not very good handled in (lib)curl.

> Curl (or my program that is linked with libcurl) then just prints out
> "Alarm clock" and exits, which is not the desired behaviour, especially
> when using the lib. I tried to activate the signal/alarm mechanism in
> url.c by uncommenting the line
> signal(SIGALRM, alarmfunc);
> added a printf statement to alarmfunc() and also put a printf before and
> after the call to connect(). But the program simply prints out "alarmfunc
> called" and still hangs in the connect() call. Any idea how this can be
> fixed?

This cannot be fixed without patching parts of the lib.

We have this problem: there's no other way to abort connect() than to use
alarm() when we're using a single-thread. If we get the SIGALRM we can catch
the signal (using signal() like above) but then the connect() won't actually
abort. If we don't catch the signal, it'll kill our process and thus our
parent process will say "Alarm clock" when we've died.

... what I fail to understand, is why you have this alarm() stuff activated
at all? Wasn't your problem that your connect() call timed out? (According to
some sources I could dig up quickly, BSD implementations have a default
timeout of 75 seconds for connect().)

So, you basically like to extend the default timeout time, right?

-- 
  Daniel Stenberg -- curl project maintainer -- http://curl.haxx.se/