www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Thread.sleep (DMD 2.020)

reply John C <johnch_atms hotmail.com> writes:
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
Nov 01 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
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
Nov 01 2008
next sibling parent reply John C <johnch_atms hotmail.com> writes:
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?
Nov 01 2008
parent Sean Kelly <sean invisibleduck.org> writes:
John C wrote:
 Sean Kelly Wrote:
 
 Should I file a bug report?



Do you mean as opposed to in its ctor? Sean
Nov 01 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
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
Nov 01 2008
parent reply John C <johnch_atms hotmail.com> writes:
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?
Nov 01 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
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?

think I'm going to remove it.

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
Nov 01 2008
next sibling parent reply John C <johnch_atms hotmail.com> writes:
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?

think I'm going to remove it.

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...
Nov 01 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
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?

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.
Nov 01 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"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?

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
Nov 02 2008
parent Sean Kelly <sean invisibleduck.org> writes:
Steven Schveighoffer wrote:
 "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?

prevent these mistakes. Aean


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.

Walter pointed out to me that by using floating point in a runtime module that's always linked (ie. Thread), the floating point support code will be linked into every app as well. This is why I changed the sleep routine in druntime.
 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.

Me too. It's silly that the core modules use a different representation for time than the other modules in Tango simply because the time structs were deemed too non-essential to place in the core. Sean
Nov 02 2008
prev sibling parent reply torhu <no spam.invalid> writes:
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.

I assume people won't need a higher resolution than milliseconds that often. Could Thread.sleep be changed into something like this? Thread.sleep(long millis, long hundredsOfNanos=0);
Nov 02 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
torhu 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.

I assume people won't need a higher resolution than milliseconds that often. Could Thread.sleep be changed into something like this? Thread.sleep(long millis, long hundredsOfNanos=0);

While Windows uses milliseconds, *nix uses either micrososeconds (usleep) or a combination of seconds and nanoseconds (nanosleep), so while using milliseconds may be more natural for Windows users it's liable to confuse others. I suppose what I'm getting at is that there's no resolution that's natural for everyone, and accepting a raw integer as a timespan is going to cause problems no matter what resolution is chosen--it's just too easy to get the number of zeros wrong. So I'd rather aim for establishing a structured form of time representation than to try and tweak the current setup. In the interim, Tango users will be happy to note that Thread.sleep() uses the same resolution as TimeSpan uses internally, so calling this routine from Tango using a TimeSpan should be pretty straightforward. Sean
Nov 02 2008
parent John C <johnch_atms hotmail.com> writes:
Sean Kelly Wrote:

 torhu 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.

I assume people won't need a higher resolution than milliseconds that often. Could Thread.sleep be changed into something like this? Thread.sleep(long millis, long hundredsOfNanos=0);

While Windows uses milliseconds, *nix uses either micrososeconds (usleep) or a combination of seconds and nanoseconds (nanosleep), so while using milliseconds may be more natural for Windows users it's liable to confuse others. I suppose what I'm getting at is that there's no resolution that's natural for everyone, and accepting a raw integer as a timespan is going to cause problems no matter what resolution is chosen--it's just too easy to get the number of zeros wrong. So I'd rather aim for establishing a structured form of time representation than to try and tweak the current setup. In the interim, Tango users will be happy to note that Thread.sleep() uses the same resolution as TimeSpan uses internally, so calling this routine from Tango using a TimeSpan should be pretty straightforward. Sean

It is: import tango.time.Time, core.thread; Thread.sleep(TimeSpan.fromMillis(50).ticks);
Nov 02 2008