Re: Hang again
- From: "Maury Pepper" <mpepper.scram.spam@xxxxxxxx>
- Date: Fri, 5 Dec 2008 18:25:51 -0600
With Cache ver. 2007.1, HANG t is very accurate for values of t with .1 sec
precision, but READ and OPEN use only the integer part of t.
Use $ZTIMESTAMP to get a UTC date,time with sub-second precision.
<al.veliev@xxxxxxxxx> wrote in message
news:94acc373-ae38-45bd-9804-f9d409fc223e@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On 4 ???, 03:20, rtweed <rob.tw...@xxxxxxxxx> wrote:
On 4 Dec, 15:17, al.vel...@xxxxxxxxx wrote:
On 2 äåê, 07:35, r...@xxxxxxxxx (Rod Dorman) wrote:
The ANSI/MDC X11.1-1995 Standard explicitly defines
_hangargument_ ::= _numexpr_
and
_timeout_ ::= : _numexpr_
Your implementation might round or truncate the _numexpr_ to an
_intexpr_ but the language itself has no such constraints.
--
-- Rod --
rodd(at)polylogics(dot)com
Cache provides for sub-second hangs and timeouts. GT.M does not.
Thanks. I checked in GT.M V5.2 sub-second intervals for HANG. It is
exact in interval 1sec-0.11sec.
A asked about the same in Cache. Cache intervals are worse - for
algorythm where I received 0.11sec in GT.M they received about 0.2sec
instead. I posted this for information.
Also my colleagues recommended in Cache to use direct interlink
between processes launched before.
They received intervals 0.02sec and processed data received from
controllers with interval 0.05sec.
But they also have problems with Open, Use and Read commands in sub-
second intervals.
Is any similar mechanism for interlink presented in GT.M?
.
- Follow-Ups:
- Re: Hang again
- From: Maury Pepper
- Re: Hang again
- References:
- Hang again
- From: al . veliev
- Re: Hang again
- From: Rod Dorman
- Re: Hang again
- From: al . veliev
- Re: Hang again
- From: rtweed
- Re: Hang again
- From: al . veliev
- Hang again
- Prev by Date: Re: Hang again
- Next by Date: Re: Hang again
- Previous by thread: Re: Hang again
- Next by thread: Re: Hang again
- Index(es):
Relevant Pages
|