This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH] gettimeofday time travels




> -----Original Message-----
> From: Philip Aston [mailto:paston@bea.com] 
> Sent: Monday, May 13, 2002 6:57 PM
> To: cygwin@cygwin.com
> Subject: Re: [PATCH] gettimeofday time travels
> 
> 
> 
> 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?

None here, but I don't know this bit of code well. Hopefully someone
else will comment.
 
> 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.

Incremental is best. Lower risk. Structure what you put in so that it
should be easily refactored, but that's all.
 
> 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.

Mutex's are the usual solution. Also there's a thread safe list in
thread.h. (It uses InterLocked calls).
 
> 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?

Not by me. There are other ways to deal though. (for example just link
to head in each object. Or, have inserts and deletes managed by the
client not the object itself.)

Rob

--
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]