digitalmars.D.learn - sleepy receiveTimeout?
- Joost 't Hart (38/38) Dec 18 2010 Hi,
- Jonathan M Davis (7/21) Dec 18 2010 You're using the wrong function (see http://is.gd/iYySf ). The correct f...
- Joost 't Hart (17/38) Dec 18 2010 Thanks Jonathan!
- Nick Voronin (5/11) Dec 19 2010 Nope, there isn't :) In ordinary multitasking environment there is no gu...
- =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= (11/23) Dec 19 2010 Note that the absence of upper bound is not related to sleep. In
- Joost 't Hart (7/16) Dec 19 2010 Surely got that bit, but I guess it makes sense to refer a bit more to
- Nick Voronin (5/19) Dec 19 2010 This all nice in theory, but are you sure that every sleep() causes sett...
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
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
On 12/18/2010 10:46 PM, Jonathan M Davis wrote:On Saturday 18 December 2010 13:22:52 Joost 't Hart wrote: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.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
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
=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> Nick Voronin wrote:On Sat, 18 Dec 2010 23:19:47 +0100 Joost 't Hart <Joost.t.Hart planet.nl> wrote: =20uarantee on upper bound.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. :-)=20 Nope, there isn't :) In ordinary multitasking environment there is no g==20Note 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 --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Dec 19 2010
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: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, JoostQuoting 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.
Dec 19 2010
On Sun, 19 Dec 2010 10:50:08 +0100 Joost 't Hart <Joost.t.Hart planet.nl> wrote: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>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 ...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.
Dec 19 2010