[omniORB] Re: Omnithread bug

[David Riddoch]

Hi Theo,


You're right, it's a bug.  Have a look at:

  http://www.uk.research.att.com/omniORB/bugs/50.html


David


On Mon, 26 Jul 1999, Theo Aukerman wrote:

> I'm using the omniORB 2.7.1 distribution on NT, and would like to thank you
> for producing a such fine CORBA implementation.
> 
> I do think I have found a bug in the omnithread library, however.
> 
> I found that when I wanted to use omni_condition::timedwait() to wait for a
> time 500 miliseconds in the future (abs time = current time + 500ms), I
> would (about half the time) get a longer wait (on the order of a few
> seconds).
> 
> The following code in omni_condition::timedwait appears to have caused the
> problem.
> ___________________nt.cc line 231___________________
>     DWORD timeout = (abs_sec-now_sec) * 1000 + (abs_nsec-now_nsec) /
> 1000000;
> 
>     if ((abs_sec <= now_sec) && ((abs_sec < now_sec) || (abs_nsec <
> abs_nsec)))
> 	timeout = 0;
> 
> __________________end nt.cc line 231________________
> 
> 
> In my circumstance, about half the time, abs_sec - now_sec == 1.  When that
> happens, now_nsec is greater than abs_nsec, forcing a wrap of the 32 bit
> value resulting in about 4 seconds being added to the timeout value.
> 
> Also, is it safe to set the timeout to 0 if the time has elapsed?  While I


I think so.  According to the Microsoft documentation, if timeout is zero
then it tests the object's state and returns immediately.


> have been debugging, I have needed to put a breakpoint at the
> WaitForSingleObject() call, and manually change the timeout to keep the wait
> from waiting forever.