[Box Backup-dev] Reviewing code -- help!

[Ben Summers]

On 11 Dec 2005, at 01:33, Chris Wilson wrote:

> Hi Ben,
>
>>> >  config.guess, config.sub -- is this necessary?
>>>  If we want to cross-compile (native win32 build using cygwin or  
>>> mingw)  then unfortunately it appears that we do need these  
>>> files. Perhaps Martin  can find a way to automatically copy them  
>>> from the user's automake  installation.
>>
>> Not terribly bothered if it's necessary, although maybe the  
>> infrastructure/makedistribution.pl script could do the copying  
>> when it's all wrapped up for release?
>
> Same problem - how do we find the builder's automake directory? And  
> I like the idea of these files being known quantities and  
> versioned, rather than subject to the vagaries of the builder's  
> machine. But I can try if you still want me to. Or we can try to  
> rewrite these scripts ourselves to avoid the license issue.

Since there is no GPL issue, there is no problem leaving them in. We  
can always deal with it later.


>
>
>>>  By the way, it compiles and runs on Win32 using MinGW. I'm just   
>>> working out some stability issues at the moment. :-)
>>
>> Great news. I'm really glad we're progressing so well towards a  
>> unified tree and then a release from which we can move forward  
>> cleanly.
>
> It now runs well on win2k when compiled with MinGW. I've had real  
> problems trying to get the free VS2003 compiler to find its own  
> libraries. I've also had problems with MinGW under emulation (both  
> vmware and qemu) where exceptions thrown in one thread cause weird  
> behaviour in other threads, leading to deadlocks.
>
> This is particularly problematic if one uses bbackupctl to start a  
> sync while the main thread is blocked in a library call like connect 
> (). I can easily and reliably reproduce this.

Is MinGW's exception handler code thread-safe? I've worked with a  
number of compilers which didn't do this properly. (And when the  
vendors were contacted, they said "well, we didn't say it had thread- 
safe exception handling in our feature list").

Sounds like there's a single global structure holding the state of  
the exception handler stack, and it's being overwritten.


>
> I created a test case that shows this weird behaviour in win2k  
> under emulation. MinGW developers have told me that my test case  
> works fine on their Windows boxes, and that they're not aware of  
> such problems in general. My test case also runs fine on a WinXP  
> box. I've yet to set up a real Win2k box to test on.
>
> Unless, for some bizarre reason, the problem is really an issue  
> with win2k and MinGW, I doubt that the mingw developers will fix  
> it, and I don't know if qemu or vmware will help me either.
>
> I've tried to compile with other compilers (Watcom, Borland C++)  
> but so far not been able to. Watcom's STL is broken (no  
> std::string!) and Borland never sent me the evaluation key for C++  
> Builder 6.

This is why I have avoided threading in the project so far! Threading  
and portability is a nightmare. And even on a single platform it's  
not too fun.

Ben