[Box Backup-dev] Re: [Box Backup] Win32 port
Ben Summers
boxbackup-dev at fluffy.co.uk
Tue Dec 6 09:59:49 GMT 2005
On 5 Dec 2005, at 22:07, Chris Wilson wrote:
>
>>> 6. Nick's BackupDaemon.cpp has a separate Windows thread for
>>> monitoring
>>> the named pipe for bbackupd control. Is this strictly
>>> required, or an
>>> improvement? 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.
So if others agree this is a fair strategy, then threading is only
there for Win32. So no need to abstract it.
>>> 11. What's the rationale for private distributions?
>>> (BOX_PRIVATE_BEGIN)
>>> i.e. what code should be protected by such sections?
>>
>> It's some other stuff I wrote. I didn't write a generic UNIX
>> daemon and client set of libraries just to use it on one project.
>> It should be pulled out of the distribution.
>
> Should I assume that nobody except you should be creating
> BOX_PRIVATE sections? (not that it matters now, there aren't any
> left in the win32 port).
Yes, fair assumption.
>>> 14. The emulation library provides stubs for lstat and readlink
>>> which do
>>> nothing, since Windows doesn't have symbolic links. I suggest
>>> that we
>>> remove these and disable any tests or code that requires
>>> them on
>>> Win32. Otherwise they may present a hazard for the unwary
>>> coder in
>>> future.
>>
>> I would prefer that they threw an exception so that #ifdefs are
>> minimised. Although the tests can't get much more ugly.
>
> If they throw exceptions, then the tests will have to do something
> like this:
>
> #ifdef WIN32
> TEST_CHECK_THROWS(<readlink call>, SomeException, SubType)
> #else
> TEST_THAT(<readlink_call> == 0)
> #endif
>
> Is that better than just #ifndef WIN32 around the call?
Well yes and no. I personally would just #ifndef WIN32 it, but maybe
I'm being lazy rather than strictly correct.
> If so then I'm happy to implement it, if you can tell me what kind
> of exception you'd like it to throw. Although I personally prefer
> that such code is checked at compile time rather than runtime.
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.
Common/NotImplementedOnThisPlatform sounds like a nice exception name
to me.
>
>
> I'm eagerly awaiting a barrage of criticism for my own misdeeds in
> the name of the porting effort. :-)
I will have a look as soon as I can.
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!
Ben
More information about the Boxbackup-dev
mailing list