I think Thread.sleep, which was introduced in core.thread in 2.020, is broken on Win32. No matter what value I pass to the function, it merely sleeps for 1 millisecond. Looks like the problem is here:

  period = period < TICKS_PER_MILLI ?
    1 : // <------------------------------------------------- BUG?
    period / TICKS_PER_MILLI;

Should it be testing if period is greater than MAX_SLEEP_MILLS, rather than less than TICKS_PER_MILLI?

Should I file a bug report?

John

John C wrote:
> I think Thread.sleep, which was introduced in core.thread in 2.020, is broken on Win32. No matter what value I pass to the function, it merely sleeps for 1 millisecond. Looks like the problem is here:
> 
>   period = period < TICKS_PER_MILLI ?     1 : // <------------------------------------------------- BUG?
>     period / TICKS_PER_MILLI;
> 
> Should it be testing if period is greater than MAX_SLEEP_MILLS, rather than less than TICKS_PER_MILLI?

This test was meant to make the min sleep time 1 millisecond, but I think I'm going to remove it.

> Should I file a bug report?

Don't bother.  But thanks for the report.


Sean

Sean Kelly Wrote:

> > Should I file a bug report?
> 
> Don't bother.  But thanks for the report.
> 
> 
> Sean

Also, any reason why priority is only available once the Thread's handle has been created - ie, after it's been started?

Sean Kelly wrote:
> John C wrote:
>> I think Thread.sleep, which was introduced in core.thread in 2.020, is broken on Win32. No matter what value I pass to the function, it merely sleeps for 1 millisecond. Looks like the problem is here:
>>
>>   period = period < TICKS_PER_MILLI ?     1 : // <------------------------------------------------- BUG?
>>     period / TICKS_PER_MILLI;
>>
>> Should it be testing if period is greater than MAX_SLEEP_MILLS, rather than less than TICKS_PER_MILLI?
> 
> This test was meant to make the min sleep time 1 millisecond, but I think I'm going to remove it.

Oh, I should mention that Thread.sleep() actually works correctly, even with this check in place.  The sleep parameter uses a 100ns resolution, so to sleep for one millisecond you must use 10_000, while to sleep for one second it's 10_000_000.  This isn't the same as Windows, which uses a millisecond resolution.  I've tested this routine on Windows, however, and have verified that it works correctly.  The docs are wrong however, as they say 500 = one millisecond.  I'll fix that.


Sean

John C wrote:
> Sean Kelly Wrote:
> 
>>> Should I file a bug report?
>> Don't bother.  But thanks for the report.
>> 
> Also, any reason why priority is only available once the Thread's handle has been created - ie, after it's been started?

Do you mean as opposed to in its ctor?


Sean

Sean Kelly Wrote:

> Sean Kelly wrote:
> > John C wrote:
> >> I think Thread.sleep, which was introduced in core.thread in 2.020, is broken on Win32. No matter what value I pass to the function, it merely sleeps for 1 millisecond. Looks like the problem is here:
> >>
> >>   period = period < TICKS_PER_MILLI ?     1 : //
> >> <------------------------------------------------- BUG?
> >>     period / TICKS_PER_MILLI;
> >>
> >> Should it be testing if period is greater than MAX_SLEEP_MILLS, rather than less than TICKS_PER_MILLI?
> > 
> > This test was meant to make the min sleep time 1 millisecond, but I think I'm going to remove it.
> 
> Oh, I should mention that Thread.sleep() actually works correctly, even with this check in place.  The sleep parameter uses a 100ns resolution, so to sleep for one millisecond you must use 10_000, while to sleep for one second it's 10_000_000.  This isn't the same as Windows, which uses a millisecond resolution.  I've tested this routine on Windows, however, and have verified that it works correctly.  The docs are wrong however, as they say 500 = one millisecond.  I'll fix that.
> 
> 
> Sean

Now you tell me :-)

Win32's Sleep(50) seems to be the same as Thread.sleep(500_000). Is that right?

John C wrote:
> Sean Kelly Wrote:
> 
>> Sean Kelly wrote:
>>> John C wrote:
>>>> I think Thread.sleep, which was introduced in core.thread in 2.020, is broken on Win32. No matter what value I pass to the function, it merely sleeps for 1 millisecond. Looks like the problem is here:
>>>>
>>>>   period = period < TICKS_PER_MILLI ?     1 : // <------------------------------------------------- BUG?
>>>>     period / TICKS_PER_MILLI;
>>>>
>>>> Should it be testing if period is greater than MAX_SLEEP_MILLS, rather than less than TICKS_PER_MILLI?
>>> This test was meant to make the min sleep time 1 millisecond, but I think I'm going to remove it.
>> Oh, I should mention that Thread.sleep() actually works correctly, even with this check in place.  The sleep parameter uses a 100ns resolution, so to sleep for one millisecond you must use 10_000, while to sleep for one second it's 10_000_000.  This isn't the same as Windows, which uses a millisecond resolution.  I've tested this routine on Windows, however, and have verified that it works correctly.  The docs are wrong however, as they say 500 = one millisecond.  I'll fix that.
> 
> Now you tell me :-)
> 
> Win32's Sleep(50) seems to be the same as Thread.sleep(500_000). Is that right?

Yup.  There should probably be some sort of TimeSpan struct to help prevent these mistakes.


Aean

Sean Kelly Wrote:

> John C wrote:
> > Sean Kelly Wrote:
> > 
> >> Sean Kelly wrote:
> >>> John C wrote:
> >>>> I think Thread.sleep, which was introduced in core.thread in 2.020, is broken on Win32. No matter what value I pass to the function, it merely sleeps for 1 millisecond. Looks like the problem is here:
> >>>>
> >>>>   period = period < TICKS_PER_MILLI ?     1 : //
> >>>> <------------------------------------------------- BUG?
> >>>>     period / TICKS_PER_MILLI;
> >>>>
> >>>> Should it be testing if period is greater than MAX_SLEEP_MILLS, rather than less than TICKS_PER_MILLI?
> >>> This test was meant to make the min sleep time 1 millisecond, but I think I'm going to remove it.
> >> Oh, I should mention that Thread.sleep() actually works correctly, even with this check in place.  The sleep parameter uses a 100ns resolution, so to sleep for one millisecond you must use 10_000, while to sleep for one second it's 10_000_000.  This isn't the same as Windows, which uses a millisecond resolution.  I've tested this routine on Windows, however, and have verified that it works correctly.  The docs are wrong however, as they say 500 = one millisecond.  I'll fix that.
> > 
> > Now you tell me :-)
> > 
> > Win32's Sleep(50) seems to be the same as Thread.sleep(500_000). Is that right?
> 
> Yup.  There should probably be some sort of TimeSpan struct to help prevent these mistakes.
> 
> 
> Aean

That's why I wrote Mango's TimeSpan way back when...

John C wrote:
> Sean Kelly Wrote:
> 
>> John C wrote:
>>> Win32's Sleep(50) seems to be the same as Thread.sleep(500_000). Is that right?
>> Yup.  There should probably be some sort of TimeSpan struct to help prevent these mistakes.
>>
>>
>> Aean
> 
> That's why I wrote Mango's TimeSpan way back when...

Unfortunately, at the moment, that would mean putting TimeSpan into druntime (dcore?), which probably isn't going to happen.

I hope that TimeSpan can make its way into a core part of Tango eventually. Socket, for instance, uses struct timeval directly -- if I recall correctly, client code has to construct timevals, and there's no constructor provided.

"Christopher Wright" wrote
> John C wrote:
>> Sean Kelly Wrote:
>>
>>> John C wrote:
>>>> Win32's Sleep(50) seems to be the same as Thread.sleep(500_000). Is that right?
>>> Yup.  There should probably be some sort of TimeSpan struct to help prevent these mistakes.
>>>
>>>
>>> Aean
>>
>> That's why I wrote Mango's TimeSpan way back when...
>
> Unfortunately, at the moment, that would mean putting TimeSpan into druntime (dcore?), which probably isn't going to happen.
>
> I hope that TimeSpan can make its way into a core part of Tango eventually. Socket, for instance, uses struct timeval directly -- if I recall correctly, client code has to construct timevals, and there's no constructor provided.

Tango uses TimeSpan in most places (including Socket) except for core, which can't depend on other libs (TimeSpan resides in tango.time.Time).  In places where TimeSpan cannot be used, or where it was deemed undesirable, a double representing seconds is used.

My original intention for TimeSpan was for it to be in core for this reason, but I was overruled.  If I had it my way, TimeSpan would be the only representation of time in Tango.

-Steve