[m-rev.] for review: fix I/O retry bug

Ian MacLarty maclarty at cs.mu.OZ.AU
Fri Aug 12 13:24:59 AEST 2005


On 12 Aug 2005, at 11:59, Zoltan Somogyi wrote:

> On 11-Aug-2005, Ian MacLarty <maclarty at cs.mu.OZ.AU> wrote:
>> Zoltan, I'm still not entirely sure why MR_trace_find_input_arg 
>> sometimes
>> finds io.state values and sometimes doesn't.  Could you clarify that 
>> point if
>> you know the reason?
>
> Yes, I do.
>
> If the compiler knows that an argument is of type io.state, it does 
> not keep
> its value around for events after the call, since the value is a dummy.
> (In fact, values statically known to have type io.state aren't even 
> passed
> as arguments.) At later events therefore the RTTI won't include a 
> reference
> to the variable, and thus MR_trace_find_input_arg won't find it.
>
> If the compiler knows the type of an argument only as a type variable 
> T,
> then the value probably isn't a dummy, and the compiler does make sure
> that its value is available at later events (unless the argument has 
> mode
> di, in which case only events before its destruction will have access 
> to it).
> If the caller binds T to io.state, MR_trace_find_input_arg thus *will* 
> find
> the argument.
>

But what's happening is that if T is bound to io.state, then 
*sometimes* MR_trace_find_input_arg finds it and *sometimes* it 
doesn't.  Should this be possible?  If so, then under what conditions 
will the value of the polymorphic io.state argument not be found?

Ian.

--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the reviews mailing list