[M3devel] win32 AlertPause polls instead of one big wait?

[Jay K]

[was truncated..]

Oh -- it is so you can wait for more than 4 billion

milliseconds, I guess.
The chunk size of the loop is roughly the maximum

time WaitForSingleObject is allowed.
Ok.


 

btw, we could also use Win32's native "alert"

mechanism. That would save creating all the alert events.

The downside is that I don't see how to alert a wait

on Win9x. Maybe via some extra arbitrary async pipe i/o?

On NT it's just QueueUserAPC.

 
 - Jay
 






From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Fri, 11 Dec 2009 14:05:56 +0000
Subject: [M3devel] win32 AlertPause polls instead of one big wait?



Anyone know why Win32 AlertPause uses a polling loop instead of just one wait?
 
 
I'm not sure this is going to work out, but:
  I'm "rewriting" stuff to use a separate event for alerting.
  alertable goes away
  There will be two events: 
    waitEvent, for condition variables
    alertEvent, for alerting 
 
 
roughly speaking:
 
 
AlertPause: WaitForSingleObject(alertEvent)
AlertWait:
   alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0)
Alert(t): SetEvent(t.alertEvent);
TestAlert: alerted := WaitForSingleObject(alertEvent, 0);
 
 
It seems simple enough.
That shows all the ingredients.
That'll eliminate a lot of the global locking.
And then one "last" iteration to use the Java code for condition variables and the global lock will be gone.
You can't just use the Java code because it doesn't include alertability.
You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex.
The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet..
 
 
 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091211/44537c03/attachment-0002.html>