www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - sleepy receiveTimeout?

reply Joost 't Hart <Joost.t.Hart planet.nl> writes:
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
$
Dec 18 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Dec 18 2010
parent reply Joost 't Hart <Joost.t.Hart planet.nl> writes:
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

Dec 18 2010
next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Nick Voronin wrote:
 On Sat, 18 Dec 2010 23:19:47 +0100
 Joost 't Hart <Joost.t.Hart planet.nl> wrote:
=20
 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=20
 want my friend to end up in cyberspace. :-)

Nope, there isn't :) In ordinary multitasking environment there is no g=

=20

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 --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Dec 19 2010
prev sibling parent Joost 't Hart <Joost.t.Hart planet.nl> writes:
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
Dec 19 2010
prev sibling next sibling parent Nick Voronin <elfy.nv gmail.com> writes:
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>
Dec 19 2010
prev sibling parent Nick Voronin <elfy.nv gmail.com> writes:
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>
Dec 19 2010