[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