[Timber] bug (?) in ASYNC implementation

[Andrey Kruglyak]

 From timber-lang.org >> Language summary >> Time constructs:

Time windows of reactions are assigned as follows:

The time window of a reaction to an external event has as baseline the  
time instant when the event occurs, and as deadline an idealised  
instant infinitely far into the future.
In particular, the start action of a program gets as baseline the time  
instant when program execution begins.

When a message without time constraints is sent (i.e., an plain action  
is called) from a method with current baseline bl and deadline dl, the  
reaction to the message inherits both bl and dl.

The rule in the previous item can be changed by explicit program  
constructs:

The expression after t act sets the effective baseline for act to the  
current baseline plus t.

The expression before t act sets the effective deadline for act to its  
effective baseline plust.

In both cases, act can be any expression of type Action, which  
includes the time-annotated constructs just introduced. Nested  
baseline offsets are composed using addition, while multiple deadline  
offsets are resolved by selecting the minimal value. The relative  
order of after and before constructs is not relevant.


Special case: if the baseline denoted by an after construct is an  
already passed time instant, the effective baseline of the reaction is  
rounded off to the actual time of the call.

Regards,
Andrey

On Oct 26, 2009, at 10:01, Ivan Tarasov wrote:

> I'm trying to understand what constitutes an RTS and how a Timber
> program translated into C is actually executed. So, I'm reading the
> RTS implementations' code.
>
> In rtsARM/rts.c, in ASYNC implementation, lines 439-442 we can see the
> following code:
>            if (LESS(m->baseline, now)) {
>                m->baseline = now;
>                // debug("^");
>            }
> Same code is present in ASYNC implementation in rtsPOSIX/rts.c,  
> lines 354-355
>
> That means that if the absolute time value for the baseline for the
> action to be scheduled is in the past, we set the baseline to the
> current time. However, since all the time calculations are relative to
> the baseline, that would mean that all the following actions to be
> scheduled from the one being scheduled at the moment would "drift". Is
> this an intended behavior? I'm not sure that's the right decision.
>
> Ivan
> _______________________________________________
> Timber mailing list
> Timber at haskell.org
> http://www.haskell.org/mailman/listinfo/timber

------------------------------------------------------------------------
Andrey Kruglyak
PhD student

http://www.andreykruglyak.com

Dept. of Computer Science and Electrical Engineering
Lulea University of Technology, Lulea, Sweden
T +46 920 49 23 57 (office)
T +46 706 16 76 03 (mobile)
Office A2314 (A-huset)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/timber/attachments/20091026/306493c1/attachment.html