>
> However, the patch means implicitly calling curl_multi_perform therefore
>> blocking the thread although it had the opportunity to take a breath and
>> could give the calling thread broad opportunities [ either to continue
>> processing with the current FTP connection or do some other useful work in a
>> timely manner ].
>>
>
> "Could" does not mean "should" though. Through the years
> curl_multi_perform() returned CURLM_CALL_MULTI_PERFORM to offer exactly that
> kind of opportunity. We never ever saw any app take advantage of that, we
> only saw lots of misunderstandings and plenty of loops do {} ... while (rc
> == CURLM_CALL_MULTI_PERFORM).
>
> A few years ago we stopped returning CURLM_CALL_MULTI_PERFORM and now the
> API is simpler.
>
> The net effect of my suggested change will be that libcurl runs a little
> longer before it returns while keeping the code slightly easier to
> understand. It still won't block hanging on a socket operation somewhere.

Only one objection. In my opinion, libraries (especially OpenSource
libraries) should not favor easy usability against more functionality. Best
example would be OpenSSL which is recently becoming an "easy to use" library
but has been used widely for many years.

>
> So I would much prefer [ if possible of course ], looking for
>> _writability_ on the control connection with "select" call to call
>> curl_multi_perform instead of triggering the state machine by setting
>> CURLM_CALL_MULTI_PERFORM.
>>
>
> Everything is possible of course. As I disagree with your opposition in the
> first place I don't think it is worth it. But if we would do it the way you
> suggest, we would have to add code to lib/ftp.c that figures out what to
> wait for outside of the FTP state machine, or possibly add multiple STOP
> states so that we can treat them differently.
>
> I would say that we have much bigger fish to fry if you really want to
> address parts of the code that is truly blocking. Like the handling of the
> server connecting back to the client after a PORT/EPRT command has been sent
> and a few other areas mentioned in bottom of the libcurl-multi(3) man page.
>
> For this particular problem, I'll proceed with my approach now and if
> someone feels like doing it differently then I'll listen and review their
> suggest patches.
>

I think I will do it myself and provide a patch set before the new year if
my schedule permits me to get accustomed to libcurl internals. My first aim
will be [ as you pointed out ] removing the blocking parts in FTP and then
the small catches [ like this one ].

-- 
it is twice as difficult to debug a program as to write it. Therefore, if
you put all of your creativity and effort into writing the program, you are
not smart enough to debug it.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-10-27