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

No problem. I don't think chunked request bodies have wide support or
use cases outside of mobile devices. I was a bit worried about people
possibly expecting "-T." to upload an entire directory contents, but
maybe that's unreasonable.

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

Sure thing, I have an updated patch at the bottom of this message
that includes the man page addendum.

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

Totally understandable. I'll try to find some time myself and look into
a migration to the multi interface and hopefully not break anything. Of
course time is always a limiting factor and my own projects are also
time-constrained.

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

Agreed. I'm more worried about regressions but I suppose the test suite
should cover a good chunk of stuff people care about.

Parallel downloads isn't a problem I myself am interested in, but I'll
keep it in mind if I implement the multi stuff. My personal approach to
parallel downloads has been writing one-off GNU Makefiles to launch curl
from :)

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

Good to know :) I use curl heavily for all sorts of work and play
things and would be very annoyed if somebody (myself included) slipped
regressions into it.
Received on 2009-08-20