On Mon, May 13, 2002 at 09:56:58AM +0100, Philip Aston wrote: > >Philip Aston writes: > > Christopher Faylor writes: > > > The correct solution is to resync after events which cause the > > > clock to stop. > > > > OK, I'll have a crack at this over the weekend following David's > > hints. > >Short of some unexpected wParam values, which I'll track down, I now >have this working. > >I have some design questions. Please help me ensure my patch is up to >scratch.. > >1. Currently I'm leveraging the event loop for the hidden window that >is created for alarm and ualarm support (window.cc). This involves a >call to gethwnd() create that window if it doesn't exist. I presume >this is fine as the socket support does the same. Any objections?
If there is any way to avoid starting up the windows event-loop thread, it should be investigated. Normal cygwin apps do not start this thread and so it should be avoided if possible. >2. Should I implement a generic mechanism for listening to power >events? Currently I've just added a static hires::reprime() method >which is called on the appropriate power event. General is always good. >3. The reprime() method iterates over a linked list of hires objects. >The hires ctor inserts a hires into this list. Do I need to worry >about thread safety here? If so, what's a typical solution? I didn't >see any handy thread safe list. It may make sense to just make all of the members of the hires class static since they are just maintaining global state. >4. Similarly for the dtor - I'm planning to assert here, rather than >faff with a double linked list. This means that hires's can never be >deleted. OK? There is no reason to delete hires as cygwin uses them. However, to answer your general question, a 'muto' is what is normally used internally for locking. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
