12 Mar 2007, Bryan Henderson wrote:

> >I would also like someone to clearly show us the benefits of using
> >pselect() and ppoll() in libcurl
>
> I assume you're talking about the benefits of using them instead of
> select() and poll(). I'd like to get into that, but it isn't germane
> to the present patch, because the patch doesn't do that.

No ?

I really think I'm not wrong when saying, that what you actually are
after is to modify libcurl in whatever is needed so that libcurl can
be interrupted not only from the client app but also with any signal
and also trying to minimize to the absolute minimum the latency which
could exist until libcurl gives back control to the client app.

As you know, you can already cancel the transfer from the progress
callback. In its current state the latency, or time libcurl will take
to abort the transfer is the worst case the sum of the following two
times:

1) If libcurl happens to be in select() or poll() at most it will
spend one second there.

2) If the progress callback has been called before in the same second
it will take another second until the client app progress callback is
called, and actually has the opportunity to interrupt the transfer.

As you see libcurl is already capable of being interrupted. With a
mean latency of one second.

Your patch tried to minimize the latency of both factors.

Reducing the first latency factor can be addressed in two ways. The
simplest method would be to reduce from 1000 ms the timeout in
select() and poll() calls to just 500 or 250 ms. The other way would
be to allow select() and poll() calls to be interrupted by signals,
and this is the solution I think is not worth due to the problems it
would introduce.

Reducing the latency of the second factor I've mentioned above can be
done calling the progress callback more frequently _and_ allowing it
to call the client app progress callback with a higher rate than once
a second.

Your patch also tried to minimize this latency but introduced some
problems see http://curl.haxx.se/mail/lib-2007-03/0109.html

I really think the way to go with all this is:

First of all modify Curl_pgrsUpdate in such a way that it calls the
_client_ app progress callback more frequently than once a second
without breaking calculations. Taking in account that CPU usage should
not skyrocket. This would be a single patch by itself.

Second, add additional calls to Curl_pgrsUpdate if actually needed.

Test if the above changes gives you the extra responsiveness you seem
to need from libcurl.

And as a last resort reduce from 1000 ms the timeout in select() and
poll() calls to just 500 ms. Nobody wants busy loops eating CPU.

> [...]
>
> There are about a dozen ways I can think of (many already discussed in
> the past few weeks) to add additional interruptibility to libcurl, and
> I tried to structure things so they will fit in easily when someone
> chooses to do the work. But the existing patch still looks like an
> improvement over status quo to me.

Sorry to say it again. But no. Your general idea is fine, but that
patch implementation is a real problem for what I, and others have
already said.

-- 
-=[Yang]=-