On Sun, 7 Jun 2009, Eric Wong wrote:

> If attempting to read from stdin returns EAGAIN, then we pause our sender.
> This leaves curl to attempt to read from the socket while reading from stdin
> (and thus sending) is paused. A 1-second alarm is set to the reader to
> retry stdin.

I would propose to instead use the write and progress callbacks to get to know
when 1 second has passed. It'll make it more portable and less #ifdef'ed.

> A better solution would be to move to the curl_multi_* interface allowing us
> to poll() stdin along with the TCP socket, but that's probably a bigger
> project.

It is, indeed. But yes that's where we should go one day. For several reasons.

> +#if defined(HAVE_SIGNAL_H) && defined(HAVE_ALARM) && \
> + defined(HAVE_FCNTL_O_NONBLOCK)

This is of course rather limited. We have 4 or 5 or so different non-blocking
methods supported in libcurl...

> +/* maybe we could just use Curl_nonblock() instead ... */

Yeah, if that would be accessible. We could poke the libcurl code to at least
provide a curlx_ version so that we don't have to re-invent the code for the
curl tool, and then we'd get the non-blocking function fairly portable.

> + } else if (S_ISFIFO(st_buf.st_mode) || S_ISSOCK(st_buf.st_mode)) {

I'm curious. Do we really need to check for fifo or socket? I mean can't we
blindly just try to set it non-blocking and act on it if successful, otherwise
do the old way?

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html