Prev: Ball of String
Next: How to have access to all tcl procs and vars in a given interpreter
From: Jens Haines on 10 May 2010 03:13
Hi,

Thank you all for your kind help. Since the program is only running on
windows, I think I'll go with the twapi package. There is a function
called "get_system_time" which should deliver the system time as the
number of 100 nanoseconds since 01.01.1601. This sounds good enough for
my purpose.

Thanks again,
Greetings Jens
From: Uwe Klein on 10 May 2010 03:36
Jens Haines wrote:
> Hi,
>
> Thank you all for your kind help. Since the program is only running on
> windows, I think I'll go with the twapi package. There is a function
> called "get_system_time" which should deliver the system time as the
> number of 100 nanoseconds since 01.01.1601. This sounds good enough for
> my purpose.

My (tentative) guess is you will see similar granularity there.
( report back when you have tested the twapi way? )

uwe
From: Jens Haines on 12 May 2010 03:53
Am 10.05.2010 09:36, schrieb Uwe Klein:
>
> My (tentative) guess is you will see similar granularity there.
> ( report back when you have tested the twapi way? )
>
> uwe

Hi Uwe,

I tested the twapi system call, and you are right. The 'get_system_time'
system call is more precise then the clock microseconds command, but the
system time which it returns is only updated every few milliseconds. So
the system call cannot be used in my delay function.

What I'm using now is a simple for loop as delay. This is not very
elaborate (and platform independent), but does the job for me.

Thanks again,

Greetings
Jens
From: Alexandre Ferrieux on 12 May 2010 04:11
On May 12, 9:53 am, Jens Haines <bubblegumtr...(a)arcor.de> wrote:
> Am 10.05.2010 09:36, schrieb Uwe Klein:
>
>
>
> > My (tentative) guess is you will see similar granularity there.
> > ( report back when you have tested the twapi way? )
>
> > uwe
>
> Hi Uwe,
>
> I tested the twapi system call, and you are right. The 'get_system_time'
> system call is more precise then the clock microseconds command, but the
> system time which it returns is only updated every few milliseconds. So
> the system call cannot be used in my delay function.
>
> What I'm using now is a simple for loop as delay. This is not very
> elaborate (and platform independent), but does the job for me.

One thing I fail to understand here is why you completely drop the
usleep()-like call for a busy loop, based on the absence of a proper
time-reading function.
These things are orthogonal: you might very well have a precise
sleeper and a less precise time-reader (who knows).
Granted, your sleep will be "blind" and drifting, but still more
efficient than a busy loop.

-Alex

From: Jens Haines on 12 May 2010 11:36
Am 12.05.2010 10:11, schrieb Alexandre Ferrieux:
>
> One thing I fail to understand here is why you completely drop the
> usleep()-like call for a busy loop, based on the absence of a proper
> time-reading function.
> These things are orthogonal: you might very well have a precise
> sleeper and a less precise time-reader (who knows).
> Granted, your sleep will be "blind" and drifting, but still more
> efficient than a busy loop.
>
> -Alex
>

Hi Alex,

I could not find an equivalent of usleep in twapi and I'm not very
familiar with using Ffidl. The usleep approach seems to be the way to go
if you want to get a real microsecond delay.

I needed to get the program to work quickly though, so I decided to use
the quick and dirty method with the busy loop. But thank you very much
for your help anyway.

Greetings
Jens
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Ball of String
Next: How to have access to all tcl procs and vars in a given interpreter