On Wed, Jul 31, 2013 at 11:50 AM, Jonathan S. Shapiro <[email protected]>wrote:
> You are assuming that the box containing the independent pointer is in >> fact independent. Because of the introspection and concurrency features of >> CLR, this assumption is wrong *in the CLR*. >> > I'm curious how this is true. Are we talking about normal CLR libraries? (I'm not thinking of the debugger interface, since that's non-standard, not safe, and a totally different ball of wax) I see the StackFrame<http://msdn.microsoft.com/en-us/library/System.Diagnostics.StackFrame.aspx> class in System.Diagnostics, but I don't see any way to access locals. Is there a way to see and modify another stack's locals or registers from within the CLR? How? When I am addressing concurrency I can specify the behavior and write the >> code to produce the desired result. >> > > Not knowing you personally, I hesitate to comment on whether you > personally can do that. I'm quite confident that the overwhelming majority > of programmers *can't* do that, and that I don't know even *one* expert > programmer who can accomplish this with 100% consistency. > I'm 100% sure I can *not* write concurrent code with 100% consistency! I don't think it's a stretch to say we would all love better tools in the toolbox for handling concurrency. That said, if the runtime *enforces* a solution to this problem, like shared-nothing, it can quickly fail my rule #3 and we jettison it when trying to achieve certain expressions it disallows. It might still be popular like Python, Ruby, node.js, etc. etc. However, I wouldn't call any of them systems-programming-runtimes. If there is a shared-nothing systems runtime, I wouldn't yet call it successful. I think we're in enough hot-water with the runtime costs of bounds-checking as it is!
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
