Hi Bert,
On Mon, May 21, 2012 at 7:33 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
> Even with a sensible timeout of 20/30 seconds instead of half an hour, that value would still be much too high for blocking a GUI tool. The cancel problem must also be fixed.
1) serf uses non-blocking i/o, the only place where it can block is in
its call to apr_pollset_poll where it waits for network events. The
timeout for this call can easily be reduced to 1 second or less. This
should solve the "cancel while waiting for network traffic" scenario.
2) ra_serf can also loop without checking a cancel action, in the
response handlers svn_ra_serf__handle_xml_parser and
svn_ra_serf__handle_discard_body. While the handler is processing lots
of data, e.g a large xml report, and as long as there's data to read,
it will stay in the reading/handling loop.
The response handlers have to get access to the session object to
check on cancel_func, which they don't have right now, but that seems
like an easy thing to fix.
I don't think there are other places besides these, unless you had
other scenario's in mind when you created the issue?
> You press ‘Cancel’ in the TortoiseSVN dialog…. And have to wait for 30 minutes until it is processed.
>
> On *nix you don’t have this problem for handling ^C, as that breaks IO, but in GUIs that doesn’t work.
>
> Bert
>
Lieven
Received on 2012-05-21 20:48:18 CEST