I agree with David here,,,i think this is an element that has not worked .. What is the point of providing these safety gaurantees ( which has a cost eg bounds checking) when you data gets mutilated and your app goes foobar if you dont do the right things anyway ...
The concurrency of the runtime / language should be the memory safety is guranteed if you do the right locking. Maybe you could have some sort of safe concurrency scope but i would not make it default. Ben On Thu, Aug 1, 2013 at 2:50 AM, Jonathan S. Shapiro <[email protected]>wrote: > On Wed, Jul 31, 2013 at 11:31 AM, David Jeske <[email protected]> wrote: > >> On Wed, Jul 31, 2013 at 10:44 AM, Jonathan S. Shapiro >> <[email protected]>wrote: >> >>> The problem is that the slot containing the *reference* to the vector >>> is mutable. >>> >> >> I don't understand why these concurrency issues are getting dragged in. I >> really dislike the idea of the bare runtime enforcing concurrent behavior >> interactions. >> > > If the runtime is responsible for enforcing memory safety, and the runtime > admits concurrency, then its implementation has to take into account the > potential memory safety impacts of concurrency. > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
