Re: question about multiwindow mode and application icons

[Harold L Hunt II <huntharo at msu dot edu>]

Earle,

> Good point, I don't know what I was thinking about WM_USER, you're 100% 
> correct
> that it shouldn't be done in a WM_COMMAND, it's a valid message on its 
> own.  I've
> been programming Windoze since Win 3.1, I should've known better!

Heh heh... no problem.

> That's quite odd!  The XMsg thread explicitly sets the error handler to the
> WM error handler, and there's no legal way for it to get into that function
> since it's not referenced anywhere in the code.  I can't reproduce what 
> you're
> seeing, at least not on a single machine.  If its repeatable on your 
> end, can
> you try commenting out the pthread_create for the XMsg proc and seeing 
> if it
> occurs again?  Running xfig locally eats up 100% CPU when doing anything 
> for
> me, maybe there's a race condition somewhere that only shows up when the
> scheduler is overtaxed?  FWIW I had seen the clipboard thread die under
> the version of the server the cygwin setup installs, after running some EDA
> tools but it's not something I took note of or kept logs.  And that rev is
> so far behind the one you're at that it probably doesn't mean anything.
>
> Looking over the XMsg function code the only thing I can think of is that
> it needs to wait on the pProcArg->ppmServerStarted mutex, which it's not 
> doing
> presently since the comments make me think that only thread needs to do 
> this
> to kickstart the main server, and it's already being done in the clipboard
> and the WM thread.  Also, since the thread opens the server before it
> sets the error handlers I imagine the server process is up and running
> when the error handlers are installed.

I think found the race condition and fixed it.

From the manual, it sounds like XInitThreads is only supposed to be 
called once per process... either that, or, it is simply not thread 
safe.  I added the ppmServerStarted mutex code to winMultiWindowXMsgProc 
() and moved the unlocking of the mutex in all thread functions to occur 
after the call to XInitThreads.

Now, those blocks of three ERROR messages that I was getting from 
winClipboardErrorHandler () are now in the same place, but they are 
coming from winMultiWindowWMErrorHandler (), as they should.

So, it looks like we were having a problem with Xlib delivering events 
to the wrong thread.  Playing it safe with XInitThreads seems to have 
taken care of this problem.  I can now run with -multiwindow and 
-clipboard safely.

Harold