Hi Bert, On Mon, May 21, 2012 at 7:33 PM, Bert Huijben <[email protected]> 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
