On 20.09.2012 23:35, Stefan Fuhrmann wrote: > On Thu, Sep 20, 2012 at 9:22 PM, Branko Čibej <br...@wandisco.com> wrote: > >> On 20.09.2012 13:41, stef...@apache.org wrote: >>> +Bottlenecks to address: >>> + >>> +* frequent cancellation checks (intense OS interaction) >> I don't understand this part: since when do cancellation checks involve >> interaction with the OS? I thought the cancellation flag was an (atomic, >> volatile) thing that requires neither cpu-level atomic operations, nor >> higher-level locking. >> > It may not actually be "the OS" but the phenomenon is real. > check_for_error() in ra_svn/editorp.c calls apr_poll(), which in > turn calls select(). > > To make things worse, we buffer small output data like props > etc. but check for errors after each of them. So, more select() > calls then socket writes ...
OK, so this is actually the server looking for abort commands from the client, which is a bit different than the client checking the cancellation flag. :) > My idea is to short-circuit the check until at least x amount > of data has been sent. I'd expect that the same select/poll that waits for the write end of the socket to become ready can also notice that the read end has data available; making the whole thing asynchronous. Blindly sending data after the client aborted the edit seems like the wrong way to solve throughput issues. Of course, taking a quick look at the implementation, this might involve rewriting all of ra_svn's network layer ... -- Brane -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
