Hi,

On Wed, Oct 25, 2000 at 08:29:23AM +0200, Daniel Stenberg wrote:

> 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 hopefully we'll get some perl hackers that add the missing features. ;-)

> > (and if the lowlevel interface of libcurl is ready, *hehe* ;-))
>
> Don't hold your breath for this.

I'm already nearly chocked. ;-)

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

Yes, that's actually my problem, the signal handler is called, but connect()
does not return with errno set to EINTR or so. And i found no way to modify
the time connect() takes to timeout.

> 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?

Well, the alarm() _was_ activated, and it always killed my perl script that's
linked with libcurl. So i tried to catch the signal with the alarmfunc()
function (the line that registers alarmfunc() as a signal handler for SIGALRM
was commented out) and the handler gets called but the connect() doesn't
return. So it may be better to disable the alarm() too and wait until
the connect() times out by itself?

> 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?

No, i wanted to shorten it to for example 30 seconds or so. I thought if it
doesn't answer within 30 secs, it'll never answer. Testing against a server
that is blocked at the firewall, connect() hangs for about 13 minutes on my
linux machine. Just for information: We're doing tests here to simulate users
of a complex web-application with menues, forms etc, and most users won't be so
patient to wait 30 secs. Then we used our tool to stress test the aplication,
we started 200 instances on a big fat Sun machine :-), and wondered why some of
them suddenly just disappeared.

Bye,
Georg
Received on 2000-10-25