On Thu, 27 Oct 2011, Gokhan Sengun wrote:

> Your patch seems to be correcting the issue.

Great! Thanks a lot for your work on pinpointing this issue and helping us out
with it.

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

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

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html