On Thu, 27 Oct 2005, iler_ml_at_fastmail.fm wrote:

> I have functions timed_connect(), timed_recv(), timed_send() that I wrote in
> the past, which are wrappers around, correspondingly, connect/recv/send.
> These functions ensure time-limits for connect/send/recv by means of poll
> without use of signals and without OS-specific socket options.

> (To make timeouts computing very easy, these functions accept both max
> amount millisec per operation and/or ending timeval. This eliminates
> need for any timeout recalculations when sequence of sends/receives is
> involved).
>
> Would it be useful if I submit a patch that removes use of signals in easy
> mode by using these timed functions ? (see P.S for compatibility
> consideration).

Sorry, but I don't see how these functions can possibly remove the need for
signals. The only place/purpose we need signals for is to abort long-running
name resolves.

But sure, I would still be interested in seeing what you mean in plain source
code since maybe then I'll understand what's so good with it! ;-) I didn't
really see your point here.

> P.S. The method of timeout handing in easy API (signals/nosignals("new"))
> can be run-time option, with default set to "signals" in order to preserve
> 100% compatibility -- in case compatibility issues can arise ?

If you can remove the use of signals and still maintain time-out functionality
on all platforms, then we could just ignore what the user sets the signal
option to.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html