Mail Archives: cygwin/2002/05/13/12:54:33
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/
- Raw text -