On Tue, 18 Aug 2009, Eric Wong wrote:

> My previous change to make stdin non-blocking by default for "-T-" actually
> broke existing behavior for some applications. It could cause the readbusy
> flag to be permanently set if the server doesn't send any data while it is
> reading data from the client.
>
> This restores previous behavior for "-T-" to not touch the non-blocking flag
> for stdin by default (the parent application can still set it, of course).
>
> Making stdin non-blocking in curl is still possible by specifying "-T."
> instead of "-T-". I chose '.' because it is an impossible name for a
> regular file.

Ok. Thanks for the fix. I've not heard anyone complain so quite clearly it
hasn't at least hit a very large amount of (vocal) people. I too think "." is
quite fine, even if I bet some systems _can_ use it as a file name.

Can you please also add a little mention of this new way to the docs/curl.1
man page?

> Has anybody investigated moving the tool over to use the multi interface so
> we can poll stdin? I think that'll be a cleaner solution and will help
> avoid freezes that can still happen right now with the non-blocking stdin
> case.

It's been mentioned in the TODO for ages and I would really like to see it
happening. Some things that have prevented it from happening so far:

A) My own time and effort in the curl tool. I'm much more focused on work in
    the libcurl side of our merry project, and even there I'm not keeping up
    with mail, bug reports and features. This makes me lag behind and even
    simply just not doing anything on the tool side of things. I'm hoping
    others will step up and fill in when the need comes. But it has slowed down
    the pace for adding of new things. Things like metalinker support died
    (or just stalled) because of my (personal) decision to basically not take
    on larger work in src/ right now.

B) It easily opens up your mind for "oh if we're going multi interface then we
    can also add support for ..." and then fill in N number of crazy far-out
    ideas! ;-) The multi interface is perfect for multiple parallel downloads
    and more. Not that new features and coolness is bad, but it takes the
    little job into the next level of then having to be something that perhaps
    is a little more thought through and planned than otherwise.

All this said, I am NOT against good suggestions or improving curl in every
possible way. I will however be more picky on getting fine patches that need
less manual work on my behalf, or even hand out CVS commit access to the brave
heroes that are willing to take on the challenges.

-- 
  / 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