[Box Backup-dev] Re: [Box Backup] Win32 port
Chris Wilson
boxbackup-dev at fluffy.co.uk
Tue Dec 6 10:53:01 GMT 2005
Hi Ben,
On Tue, 6 Dec 2005, Ben Summers wrote:
>> > > 6. Nick's BackupDaemon.cpp has a separate Windows thread for
>> > > monitoring the named pipe for bbackupd control.
[...]
>> > > My own patch set (for Boxi) does this in a different way -
>> > > no extra thread is created, but instead the main thread polls the
>> > > command socket more often. Any suggestions on which approach is
>> > > preferred? The thread stuff looks harder to make cross-platform
>> > > compatible.
>> >
>> > It's usually best to wait using the OS' provided API, rather than to
>> > poll.
>>
>> Any suggestions on how to use threads in a cross-platform way to achieve
>> this? I know wxWidgets has a cross-platform thread library, but it may be
>> a bit too heavyweight a dependency for your taste.
>
> In general, we should avoid using threads. It's a bit of a nightmare on many
> UNIX platforms, especially when you have C++ in the mix. (although this may
> have changed.) I personally would make sure that my UNIX daemons forked
> rather than used threads just to avoid any potential portability hassles.
What I want to do (but not as part of the win32 port :-) is improve
responsiveness of the bbackupd on Linux and Windows, the two platforms I
care about. I want to be able to stop an in-progress backup, or restart
bbackupd, quickly and cleanly.
At the moment, I could send it a signal, but I don't trust signals (and I
can't find the pid on cygwin yet, probably not on win32 native either). Or
I could write to the control socket, but then I have to wait for an age
before bbackupd notices. I don't think this can be used to terminate an
in-process backup; bbackupd doesn't check the command socket until it's
idle again.
Nick's written this code which uses a separate thread on Windows to check
the command socket all the time. I've written some code that polls the
command socket more often during the backup, and doesn't require an extra
thread.
I'm OK with including the thread on win32, but I'd like a solution that
works on Linux and Cygwin as well. Perhaps forking a process to monitor
the command socket and send signals to bbackupd?
Forking doesn't work on win32, so this would have to be an alternative to
the thread above.
> Well yes and no. I personally would just #ifndef WIN32 it, but maybe I'm
> being lazy rather than strictly correct.
Me too, I'd prefer the compiler to check that I don't call something I
shouldn't. Unfortunately gcc isn't smart enough to identify unreachable
code :-(
> Normally I would say a compile time failure would be better. However, those
> calls should never actually be used in this particular application, so it
> simply make it easier to code.
Ok, I'll buy that (and make them throw exceptions) if I can't find any way
for them to be called on win32 (outside of the tests).
> Incidentally, I'm a little concerned about the uncertainty of the starting
> version for the Win32 code. But I think we're (you're!) going through it
> carefully enough to make this not a big worry. Looks like it was quite a 14
> hour marathon!
Yeah, it was. I've been over the entire patch (8,900 lines) at least three
times, and five times for the changes to existing code. I found a load of
stuff that Nick had backported from 0.09 and removed it all, so that it
doesn't show up in the diff against 0.08 and it should merge OK into 0.09.
As far as I know, I've got it all out now. The remaining changes fall into
the following categories (roughly in order of decreasing size)
* Newly added files
* #ifdef WIN32 (new code inside)
* #ifdef BERKELY_V4 (which is never compiled: #undef BERKELY_V4)
* #ifndef WIN32 (around existing code)
* #ifndef BERKELY_V4 (around existing code)
* Code formatting and spelling misteaks
The only things that might be left over from older versions are the code
inside the WIN32 and BERKELY_V4 sections. This will cause a conflict on
merge, and I'll do my best to resolve it in favour of the newer code,
porting that to Win32 where necessary.
The code is actually much easier to review, if you're not too worried
about correctness on Win32, since almost all of it is #ifdef WIN32 or
BERKELY_V4.
Cheers, Chris.
--
_ ___ __ _
/ __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |
More information about the Boxbackup-dev
mailing list