Thanks for the review!

> The use of "magic numbers" are increased a lot. And by magic numbers I
> mean that the existing (before this patch) uses explit checks for -1
> and 0 on multiple places and that is already a bit on the bad side -
> as using named defines would much more readable by somewhat removing
> the need to lookup what the number actually means. Adding -2 to the
> pile thus makes the code even worse in that aspect.

Agreed.

> > It will also make the progress update function get called for
> > _every_ single call to Curl_socket_ready() and Curl_poll() no matter
> > what.
>
> Ouch, I clearly didn't read it good enough! We can't have it do that.

Okay, I will change that.

So I will add a function like Curl_checkAbort(), which will basically
call the user's progress callback, passing the current (old) state
data, without doing all the costly updating stuff in Curl_pgrsUpdate().
Curl_checkAbort() will be the function called before poll()/select()
to help minimizing race conditions, since this call is unconditional
and there should not be much pending to update there, right? After
and if poll()/select() is aborted, should I also only call this
Curl_checkAbort(), or it is worth calling Curl_pgrsUpdate() this time?

> And once that the above is in place _and_ working it would even make
> sense to internally introduce pselect() and ppoll().

Yes this is my point of view, it is the logical next step.

> Pierre, a working example for docs/examples showing its use would of
> course be also a good idea, and could be used as proof of concept if
> it is finally accepted.

Sure, I'll think about it :)

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."