On Sat, 10 Aug 2002 noreply_at_sourceforge.net wrote:

[This mail regards the multi interface ]

> Patches item #593518, was opened at 2002-08-10 21:14
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=300976&aid=593518&group_id=976
>
> this patch will still allow blocking to occur in curl_multi_perform if you
> post/put more than the socket buffer allows prior to data transfer
> (probably 16kbytes).. but for me at least it works perfectly

Thanks for your efforts and patch. I cannot however accept/apply this patch
as it is. I post this reply to the mailing list to inform the libcurl
community about what needs to be taken into consideration here. This is not
meant as a complaint on your patch in particular, but I'm merely trying to
bring several of the problems into light here so that we can get more people
actually viewing the real problem bringing really working solutions.

This is the second patch I receive for this "problem" and there are several
assumptions made here that we (we as in us who want libcurl to function as
documented) really can't approve of:

1. The connect() doesn't always succeed, just returning 0 as if it did will
   certainly work for all good connects but not for slow/bad connects.

2. Returning without waiting when using the easy interface breaks it really
   bad. Please at least make sure that the existing test suite runs before
   submitting patches.

3. libcurl supports more protocols than HTTP, we cannot add functionality to
   upper-level interface code that depends on specific features of certain
   protocols. Thus, the state machine in lib/multi.c needs to be written in
   a ways so that it works indepdently of what actual protocol is being
   served.

I find it mildly amusing that people detect and fix the "busy-waiting"
connect, while there are several other pieces of code that also will "wait"
for the proper response before returning back control to the caller. Examples
of this behavior is found here:

1. (FTP) PASV code does a second connect and waits for the connect to
   complete

2. (FTP) PORT code tells the server to connect wand after 'RETR', 'STOR' or
  'LIST' (etc) is made, the code waits for a connect from the peer.

3. (FTP) All ftp commands await responses from the server.

4. (HTTP) The HTTP request is sent in multiple pieces in case it would block
   to send the whole one.

My upcoming commit should fix the initial connect issue and issue 1 from this
list. I do have issue 2 covered in a solution in my head, and item 4 should
be pretty easy to fix as well. Item number 3 will take quite some work to
make fully asynchronous and I have no intention of doing this right now.

Feel free and encouraged to point out my mistakes, errors, stupid
assumptions, brain damages or similar.

-- 
 Daniel Stenberg -- curl related mails on curl related mailing lists please
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf