[Patch] Fix gethwnd race

[Christopher Faylor]

On Thu, May 13, 2004 at 02:58:00PM -0500, Brian Ford wrote:
>On Thu, 6 May 2004, Christopher Faylor wrote:
>>Thanks, but, I see that you're using busy loops.  I use those in places
>>where I have no choice but to do so or when the potential for a race is
>>unlikely.
>>
>>I don't think that this is really a situation that qualifies for
>>either.  It seems like a muto is a cleaner choice here.
>
>Sorry for the delay; my free time has been in short supply lately.
>
>I can't seem to make a muto fit this situation cleanly since it would
>have to be acquired and released by the same thread.

Why would it be acquired and released from the same thread?  Isn't the
problem that multiple people are calling gethwnd?  You even mention this
in the ChangeLog below.  Given that, the place to put a mutex would seem
to be in gethwnd.

So, I'm not sure this patch is the right way to go.  Sorry!

I have a patch ready.  I was waiting to see if you had something ready
by the end of the day but, unfortunately, I don't think your patch is
moving in the right direction.

Do you have a simple test case which tickles the problem, by any chance?
I'd like to see if what I've done actually solves anything.

cgf

>2004-05-13  Brian Ford  <ford@vss.fsi.com>
>
>	* window.cc (window_started): Make NO_COPY.
>	(gethwnd): Fix initialization race.
>	(window_init): New function to initialize window_started.
>	* winsup.h (window_init): Prototype it.
>	* dcrt0.cc (dll_crt0_1): Call it.