Hi Brad, Brian ---
Brad -- thanks for that very detailed explanation. I think all of it makes
sense -- although it does make it clear that reasoning about eg. the locality
of an object from the source code is sometime subtle.
However, your discussion of const ref/in for record types brings up another
oddity. Consider the following :
record R {
var x : int = 3;
proc setX(y : int) {
x = y;
}
}
proc main() {
const r : R;
writeln(r);
r.setX(10);
writeln(r);
}
If I run it, I get :
(x = 3)
(x = 10)
Even though r is defined to be constant, it clearly is being changed --- and I
believe that's because Chapel methods today don't have any notion of
const-ness. So, eg. marking an record const ref/in going into a forall loop by
default will not prevent a user from creating a data race. Furthermore, I
suspect this might break the remote forwarding semantics... although I haven't
tried to verify this.
Thoughts?
-- Nikhil
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
