> On Wed, 16 Apr 2008, Yang Tse wrote:
> > There has to be a _new_ user provided callback (abort check
> > callback) which somehow will find out and tell to libcurl if libcurl
> > should abort or not.

Then it will look pretty much like the first patch that I posted. To
which Daniel suggested I should in the contrary use the existing
progress callback :)

> If you really need this kind of check before every select()/poll()
> call, isn't it just easier (and better) to just switch and use the
> multi interface ?

Well no, this check is not *needed*. Actually we may be thinking the
wrong way: this extra check is just a hack to make up for the lack of
proper, safe signal handling with signal masks and ppoll()/pselect().
It would eventually not be there at all on platforms that support
ppoll()/pselect(). So, as "just a hack," it should not decide how the
main stuff is implemented.

So if I can't find a simpler, better way to work around the race
conditions, I'm just going to remove this extra call altogether for
now :) Independently of the availability of ppoll()/pselect(), proper
signal blocking is enough to minimize race conditions, without the need
for such an extra call.

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