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);

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

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

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

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);