Re: Linux nanosleep investigation.

[Kevin Hendricks <khendricks at ivey dot uwo dot ca>]

Hi,
 
> What won't work properly? Are you going to burn a CDROM, your videocard,
> your nic, or whatever?
 
The real issue here is that if nanosleep is constantly
being interrupted by numerous signals almost immediately after it gets entered
and you add that one extra jiffee in rounding up, could the remaining time that
is returned theoretically be larger than the initial time requested or show no
elapsed time at all?

If it can return with remaining
time having one jiffee more that then requested time of equal to the requested
time then under high signal environments, we can't use nanosleep to keep track
of time in simple way for pthread_cond_timedwait.

If your change fixes that issue (so that at least one jiffee is used up with
every call) then I think your patch is fine.  

I apologize Andrea for not reading
your patch but it never hit the canada mirror (or at least not by last night, I
could not find it on the us mirror and eventually found it on the german mirror
but it got hammered when being downloaded last night and I could not read it
(my net connection is not always great...one of the big advantages to living in
the great white north) ;-)

The rest of this argument I have seen so far seems like semantics at best. 

Andrea If your patch fixes those issues that that's great and thank you!  If
not, could you please try again (if possible) so that nanosleep remaining time
can only elapse (get smaller) even in high signal environments.

Kaz, given your arguments, we will have to simply keep track of time using
gettimeofday in pthread_cond_timedwait and that is fine since it is passed an
absolute timeout anyway, this is not an issue.


I hope this has helped.

Kevin



--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA   
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959