[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