Daniel Stenberg <daniel_at_haxx.se> wrote:
> 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.

Done with the write callback. I actually did this initially but was
thrown off it because nobuffer wasn't being enabled correctly. It's
much cleaner and quicker now.

>> +#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.

Yup, that'd be nice. Should we just replace the old one since with the
curlx_nonblock() name since the old one was never public anyways?

>> + } 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?

Just a little paranoia on my end; but then I have yet to encounter a
kernel that panics or corrupts files with this behavior so it's probably
safe to remove :)

Here's a cleaner patch which removes the alarm() dependency
by unpausing the read when the write callback is called.
Let me know how/if you want to handle the Curl_nonblock() => curlx_*
change.
Received on 2009-06-08