Some update on Cygwin hangs

[Kelly O'Hair]

Given Windows poor history with doing things in a multi-thread way, is it possible that we are running into a basic
Windows issue of running too many multiple processes, or too many unix-y processes in parallel? Ones that have
historically never been run in parallel like this before on Windows?
Maybe the issue is with Windows and Unix tool kits in general, and not cygwin or msys in particular?

I recall that GNU make for the longest time did not support parallel builds on Windows at all (-j was disabled on Windows).
And our own old builds do nothing in parallel on Windows, never have. Are we asking too much from Windows?

Perhaps we need to consider doing all Windows builds with JOBS=1 or -j1, by default?

---

I know for a fact that Visual Studio does a lousy job of allowing cl.exe to run in parallel, using many default
filenames that are not unique to the file being compiled, which is why we have to use so many /F options.
Visual Studio has some of the worst license check logic too, which I have been convinced in the past could
block compilations from operating in parallel.
Having said that, hotspot builds that use NMAKE and PCH have somehow managed to build screamingly fast
and very reliable.  But it doesn't use any unix toolkits.

-kto

On Oct 22, 2012, at 9:01 AM, Erik Joelsson wrote:

> I have tinkered around with msys and initially it looked like slower but more stable. However, the slower part was due to a bug in configure that didn't detect the number of cores and amount of memory on the system correctly and thus defaulted to running make -j1. I fixed this bug, enabling concurrency for msys, but ran into frequent crashes instead.
> 
> No real decision has been made, but between me and Magnus we felt that msys didn't work too well. Running msys serially might still be the best stability option though.
> 
> /Erik
> 
> On 2012-10-22 17:56, Kelly O'Hair wrote:
>> On Oct 19, 2012, at 11:59 AM, Magnus Ihse Bursie wrote:
>> 
>>> On 2012-10-19 20:13, Kelly O'Hair wrote:
>>>> If we are not seeing this hang with MinGW/MSYS, perhaps we need to make a decision here to abandon CYGWIN?
>>> On the contrary, we're seeing a lot more instability with msys. :-(
>> I'm completely surprised by that statement, I thought you had said that msys was slower but more stable.
>> 
>>> Erik has seen lots of random crashes, I haven't seen many (just about one or two) but I have also seen hangs.
>>> 
>>> So we've basically taken the informal decision of not pushing the msys track any further. What's in there will work properly some/most of the time. It might very well be good enough for "community support", but it won't do to use in our build farms.
>> Who  was "we" here?  And what exactly is this "informal decision" that was made?
>> 
>>  And what does  "some/most" mean?
>> 
>> -kto
>> 
>>> That's the reason for the renewed efforts to get cygwin working. We concluded that there seems to be just a single issue left with cygwin: if it hangs, it hangs at the "ctsym bug", so it should be doable to  figure out what goes wrong and work around it. Msys, on the other hand, seemed much more generally unstable.
>>> 
>>> But we need to get either of them working, or we can't build with acceptable stability on Windows. So it's really a high priority issue for us.
>>> 
>>> /Magnus