Hi,

(also posted on news.gmane.org, but does not seem to appear there)

New to this group and to D, but getting "into" it fast.

Came across a problem.

2.050 / Linux

1) On windows we can get any (std.concurrency, which is what I use in my project) thread to sleep using Sleep() from core.sys.windows.windows. I cannot find the alternative under Linux...

Is there one?

2) So I wrote one myself using receiveTimeout( time, (something unused){} );

Now begins the fun. For values of time >= 500 this workaround is fine.
For values < 500 it does not work.

Where does this magic number sit?

Cheers,
Joost.

$ cat time.d
import std.concurrency;
import std.conv;

void run( long tim )
{
    foreach( dum; 0 .. 100 )
    {
        receiveTimeout( tim, (int x){} );
    }
}

void main( string[] args )
{
    run( to!long( args[1] ) );
}
$ time ./time 500

real    0m49.673s
user    0m0.000s
sys    0m0.000s
$ time ./time 499

real    0m0.972s
user    0m0.000s
sys    0m0.000s
$

On Saturday 18 December 2010 13:22:52 Joost 't Hart wrote:
> Hi,
> 
> (also posted on news.gmane.org, but does not seem to appear there)
> 
> New to this group and to D, but getting "into" it fast.

Welcome!

> Came across a problem.
> 
> 2.050 / Linux
> 
> 1) On windows we can get any (std.concurrency, which is what I use in my
> project) thread to sleep using Sleep() from core.sys.windows.windows. I
> cannot find the alternative under Linux...
> 
> Is there one?

You're using the wrong function (see http://is.gd/iYySf ). The correct function is core.Thread.sleep(). It works on both Windows and Linux. It's a static function which should work just fine regardless of whether you're using Thread directly or using spawn().

- Jonathan M Davis

On 12/18/2010 10:46 PM, Jonathan M Davis wrote:
> On Saturday 18 December 2010 13:22:52 Joost 't Hart wrote:
>> Hi,
>>
>> (also posted on news.gmane.org, but does not seem to appear there)
>>
>> New to this group and to D, but getting "into" it fast.
>
> Welcome!
>
>> Came across a problem.
>>
>> 2.050 / Linux
>>
>> 1) On windows we can get any (std.concurrency, which is what I use in my
>> project) thread to sleep using Sleep() from core.sys.windows.windows. I
>> cannot find the alternative under Linux...
>>
>> Is there one?
>
> You're using the wrong function (see http://is.gd/iYySf ). The correct function
> is core.Thread.sleep(). It works on both Windows and Linux. It's a static
> function which should work just fine regardless of whether you're using Thread
> directly or using spawn().

Thanks Jonathan!

After another minute of eyebrowing I got it working:

import core.thread;
....
void mySleep( long tim_in_millisecs )
{
    // No, not a simple ::sleep, and please do care about those numbers!
    Thread.sleep( tim_in_millisecs * 10_000 );
}

Quoting the documentation:

/Suspends the calling thread for at least the supplied period./

What does "at least" mean here? Is there also an "at most"? I do not want my friend to end up in cyberspace. :-)

I guess part (2) of my original posting still stands as a candidate bug?

Cheers,
Joost.

>
> - Jonathan M Davis

On Sat, 18 Dec 2010 23:19:47 +0100
Joost 't Hart <Joost.t.Hart@planet.nl> wrote:

> Quoting the documentation:
> 
> /Suspends the calling thread for at least the supplied period./
> 
> What does "at least" mean here? Is there also an "at most"? I do not want my friend to end up in cyberspace. :-)

Nope, there isn't :) In ordinary multitasking environment there is no guarantee on upper bound.

-- 
Nick Voronin <elfy.nv@gmail.com>

Nick Voronin wrote:
> On Sat, 18 Dec 2010 23:19:47 +0100
> Joost 't Hart <Joost.t.Hart@planet.nl> wrote:
> 
>> Quoting the documentation:
>>
>> /Suspends the calling thread for at least the supplied period./
>>
>> What does "at least" mean here? Is there also an "at most"? I do not want my friend to end up in cyberspace. :-)
> 
> Nope, there isn't :) In ordinary multitasking environment there is no guarantee on upper bound.
> 
	Note that the absence of upper bound is not related to sleep. In
ordinary multitasking environment there is no guarantee that your
program will not be stopped at some arbitrary point for an arbitrary
long time no matter what it does.

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

On 12/19/2010 09:56 AM, Nick Voronin wrote:
> On Sat, 18 Dec 2010 23:19:47 +0100
> Joost 't Hart<Joost.t.Hart@planet.nl>  wrote:
>
>> Quoting the documentation:
>>
>> /Suspends the calling thread for at least the supplied period./
>>
>> What does "at least" mean here? Is there also an "at most"? I do not
>> want my friend to end up in cyberspace. :-)
>
> Nope, there isn't :) In ordinary multitasking environment there is no guarantee on upper bound.
>

Surely got that bit, but I guess it makes sense to refer a bit more to some good old thread state names: After (exactly!) the given period of "suspension" the thread returns into "ready" state.
When (if ever) it will become the "running" thread again depends ...

Cheers,
Joost

On Sun, 19 Dec 2010 10:50:08 +0100
Joost 't Hart <Joost.t.Hart@planet.nl> wrote:

> >> Quoting the documentation:
> >>
> >> /Suspends the calling thread for at least the supplied period./
> >>
> >> What does "at least" mean here? Is there also an "at most"? I do not want my friend to end up in cyberspace. :-)
> >
> > Nope, there isn't :) In ordinary multitasking environment there is no guarantee on upper bound.
> >
> 
> Surely got that bit, but I guess it makes sense to refer a bit more to
> some good old thread state names: After (exactly!) the given period of
> "suspension" the thread returns into "ready" state.
> When (if ever) it will become the "running" thread again depends ...

This all nice in theory, but are you sure that every sleep() causes setting of hardware timer? In every OS? In every minor version of OS even? If not (and I'm pretty sure it's not so), then you need to add more details. All about how scheduler works. Or this precise talk on what happen after time is up would just mislead people. Aside from the fact that sometime after time is up thread would become runnable again (which is really obvious, no?) there is nothing to say.

-- 
Nick Voronin <elfy.nv@gmail.com>