Re: Reentrancy via Recursion

On Thu, 2009-02-26 at 06:45 -0500, Kevin Reid wrote:
> On Feb 26, 2009, at 5:46, Toby Murray wrote:
> > Would the addition of another invocation operator (on top of "." and
> > "<-") to E that means
> > "immediate-call-to-untrusted-object-that-shouldn't-be-able-to- 
> > recursively-call-me"
> > be fair? Being able to use such an operator would enable the  
> > programmer
> > not to have to worry about these kinds of bugs.
> 
> Having such an operation would expose (by whether it succeeds or  
> fails) information about the stack, and break determinism.

OK. Let me unpack a bit. Suppose we have Alice and Bob (both functions
for simplicity). Suppose Bob is defined like

def Bob() {
    Alice()
}

Bob is nondeterministic in that Bob() will fail sometimes if called in a
context during which Alice() is executing.

However, this kind of nondeterminism can already be created in E.
Suppose we have a variable 'InUse' and Bob is now

def Bob() {
   if (InUse) {
       throw "in use"
   }
}

Bob is nondeterministic in that Bob() will fail sometimes if called in a
context during which InUse is true. 

I see that the first case does reveal information that the second
doesn't -- about the call-stack. However, I don't see how it adds any
more nondeterminism than is already present. 

Are you saying that the problem of avoiding recursive-reentrancy-bugs is
insoluble (other than to be as astute as David Wagner)? I want a
solution for people like me who can't see these kinds of bugs easily. We
have one for concurrent-reentrancy (communicating event loops and
asynchronous-promise-returning-invocations), why not
recursive-reentrancy?

Cheers

Toby