[Box Backup-dev] Current status

Ben Summers boxbackup-dev@fluffy.co.uk
Tue, 13 Dec 2005 21:54:36 +0000


On 13 Dec 2005, at 21:35, Gary wrote:

> Ben,
>
>>> 1.) Whether the -chromi fast diffing patch will include
>> simultaneous
>>> diff/upload (in which case KeepAlive is pointless).
>>
>> It doesn't at the moment, and won't in the next release.
>
> Ok, so we have to run with the KeepAlive version, then. Which  
> brings us
> to the next issue:
>
>> Could we use a signal or something to throw an exception,
>> and avoid the whole polling thing?
>
> With KeepAlive, we need to be able to not only interrupt the diffing
> process (as in MaximumDiffingTime), but also resume it after a
> KeepAlive command has been executed. I think the decision on how to
> implement this best is up to you Ben, since it invasively affects the
> core BoxBackup distribution.

I think your approach is fine. We could discuss various code tidying,  
but where threads are undesirable setting boolean flags from timer  
signals and polling them in the main code is good enough. (although  
really you don't want to do anything more than setting a flag in the  
signal handler as they need to complete fast and can't call all OS  
functions: pThisCtxInst->DoKeepAlive(); I suspect does too much.)

So... set a timer for min(timeout,keep-alive-due), then in that timer  
set a flag for the required action, then an activity due flag. Poll  
that flag during the diffing process, calling a function which does  
the necessary work, sets another timer, and returns an abort flag.

I'm not sure anyone else will need the ability to do work within the  
process, so it may not be worth making a nice extensible interface  
with registered listeners.


Charles is right about Windows. The basic low level Win32 API is much  
better than POSIX, and threads and I/O are handled very nicely, so it  
makes sense to use them there. Some UNIXes allow async IO (aio_*  
functions) but they're not widely supported, but if overlapped code  
should be written, maybe it could be used in a way which is "portable"?

I would be unhappy about using threads in the POSIX versions. I know  
from painful experience that C++ and pthreads don't go well together  
on a few platforms due to non-thread-safe exception handling,  
although this may have been fixed now.

Ben