Hi guys,

the best solution would be to eliminate all the blocking stuff, of
course. Then Curl_pp_easy_statemach() could be removed,
Curl_pp_multi_statemach() renamed to just Curl_pp_statemach() and the
PP-based protocols could not get stuck in an unexpected blocking call
anymore. But that would apparently need some deeper changes.

> * smtp.c calls smtp_easy_statemach() twice - once in smtp_quit() and the
> other in smtp_done() - note there is a huge TODO comment in the latter about
> its usage!
Please note a similar hack will be needed in IMAP for proper FETCH and
APPEND handling. For some protocols it is just necessary to send or
receive some data in the DONE phase, after the data has been
transferred - ssh.c contains a similar code and even the same TODO
note in ssh_done().
If this is resolved as the note suggests, e.g. by allowing the done
handler to return CURLE_AGAIN, these cases could be made fully
non-blocking. But there is the part with "Curl_done() invokes on
several places in the code", which would need to know about this and
handle it right.

> * In ftp.c, ftp_quit() is the only user of ftp_easy_statemach()
> * In imap.c, imap_logout() is the only user of imap_easy_statemach()
> * In pop3.c, pop3_quit() is the only user of pop3_easy_statemach()
These logout-type functions are invoked from the disconnect handler
from Curl_disconnect(), which is called from various places and I'm
not sure there are provisions for asynchronous operation in all of
them. Perhaps a similar situation as with Curl_done() above.

So maybe the blocking state machine loop will have to stay after all...

>1) xxx_blocking_statemach() - For example ftp_blocking_statemach()
What about xxx_statemach_loop()? If that's what it does, loops calling
the state machine again and again till it's finished.

Kind regards,
Jiri
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-01-19