Uh, scratch that. Original patch stands. With this change, close could
still get called multiple times.
Digs hole and hides... :-(
On Fri, 14 May 2004, Brian Ford wrote:
Ugh! Ok, this falls under the too much list noise category, so I'll
just shut up now.
On Fri, 14 May 2004, Brian Ford
On Fri, May 14, 2004 at 12:20:18PM -0400, Christopher Faylor wrote:
I need to do a little debugging on what I have but it does try to clean
up the windows code slightly. I even eliminated the thread event
synchronization entirely.
This is now checked in. In the end, I implemented a new method
On Fri, 14 May 2004, Christopher Faylor wrote:
If you had said: I was trying to avoid having a persisent muto for what
is basically a one-time use that would have made a lot more sense to me.
I thought you knew it was a one time event, and my reasoning was more:
I was trying to avoid having a
On Fri, May 14, 2004 at 10:59:42AM -0500, Brian Ford wrote:
However, I'll look at your code again with my new understanding of your
intent.
No need. Just before falling a sleep last night, I remembered a case I
had not covered correctly. If the initialization fails the first time,
the event
On Fri, May 14, 2004 at 02:05:53PM -0400, Christopher Faylor wrote:
I couldn't see anything in MSDN which supported it.
Found it. It was in the GetMessage description. Oh well.
cgf
On Fri, 14 May 2004, Christopher Faylor wrote:
Well, maybe I didn't do anything, since that is exactly what I did after
investigating MSDN. I thought I remembered that this was the case but
I couldn't see anything in MSDN which supported it. I suppose I should
just have trusted Sergey on
Ugh! Ok, this falls under the too much list noise category, so I'll
just shut up now.
On Fri, 14 May 2004, Brian Ford wrote:
+ HANDLE ws;
+
+ if (InterlockedDecrement (window_waiters) == 0
+ (ws = (HANDLE) InterlockedExchange ((long *) window_started, 0)))
+CloseHandle (ws);
This
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
On Thu, 13 May 2004, Brian Ford wrote:
On Thu, 13 May 2004, Christopher Faylor wrote:
I'd like to see if what I've done actually solves anything.
Me too ;-).
PS. In case it wasn't obvious, none of that was meant to offend. I'm
genuinely curious to see how you approached the issue. I still
On Thu, 13 May 2004, Brian Ford wrote:
On Thu, 13 May 2004, Christopher Faylor wrote:
If it does exist, just return it. No locking required.
Ok, add:
if (ourhwnd)
return ourhwnd;
to the beginning of my patch if your worried about the interlocked
overhead and don't mind a double
On Thu, May 06, 2004 at 07:18:39PM -0500, Brian Ford wrote:
Although not the complete rewrite you may have been hoping for, the
attached patch does appear to fix the:
Winmain: Cannot register window class, Win32 error 1410
portion of this bug:
On Fri, May 07, 2004 at 04:51:42PM +0200, Jacek Trzmiel wrote:
On Thu, May 06, 2004 at 07:18:39PM -0500, Brian Ford wrote:
Although not the complete rewrite you may have been hoping for, the
attached patch does appear to fix the: Winmain: Cannot register window
class, Win32 error 1410 portion of
On Thu, May 06, 2004 at 07:18:39PM -0500, Brian Ford wrote:
Although not the complete rewrite you may have been hoping for, the
attached patch does appear to fix the:
Winmain: Cannot register window class, Win32 error 1410
portion of this bug:
Although not the complete rewrite you may have been hoping for, the
attached patch does appear to fix the:
Winmain: Cannot register window class, Win32 error 1410
portion of this bug:
http://www.cygwin.com/ml/cygwin/2004-05/msg00232.html
I still see:
recv: No buffer space available
but have
14 matches
Mail list logo
