Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!apple.com!Piersol
From: Piersol@apple.com (Kurt Piersol)
Newsgroups: comp.object
Subject: Re: Reentrant code
Message-ID: <4540@internal.Apple.COM>
Date: 4 Oct 89 00:21:05 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 54
References:<11242@eerie.acsu.Buffalo.EDU> <4513@internal.Apple.COM> <24517@dcatla.UUCP>

In article <24517@dcatla.UUCP> itwaf@dcatla.UUCP (Bill Fulton [Sys Admin]) 
writes:
> (Messages are specific to certain implementations of OOPS)

Now here's an interesting thought. Am I in fact incorrect in assuming that 
all OOP systems contain some concept of messaging? I have difficulty 
imagining why one would bother with OOP at all without an idea of 
messages, and the fact that the same message selector or ID or whatever 
has differing behavior based on the receiver or the product of receiver 
and arguments. I can recall a few systems claiming to support OOP which 
had no message concept, but instead claimed operator overloading amounted 
to the same capability. I suppose I just dismissed that notion out of 
hand. What say the rest of you?

> I think it's the definition of 're-entrant'
> that's the problem. My understanding is that a block of re-entrant code 
must
> support *concurrent* execution by different processes, not just 
sequential
> execution by different callers in the same process. Thus, instance data 
must
> be part of the "machine state" which is saved.

As has been mentioned earlier in this series of messages, there are 
several possible methods by which one can re-enter the same code. Since in 
class based systems (or prototype based systems for that matter) the code 
for all instances (or inheritors) is generally stored in a single 
location, it must be compiled such that the code depends only on the state 
of the object in which it is being executed (and perhaps some temporary 
variables associated with the method). Otherwise, one would have the 
annoying behavior of mixing state from several instances. As a side effect 
of this requirement, the code becomes reentrant. The same method (or 
whatever one wishes to call the code which responds to a message) can be 
independently in use by several objects in separate threads, or repeatedly 
within a single recursion chain (especially in cases of mutual recursion).

However, if the SAME OBJECT is being used in several threads, some care 
must be taken lest its internal state become corrupted. Therefore, the 
objects, as opposed to their code, are not necessarily reentrant.

Did this make more sense? The reentrancy is a side effect, but still there.

Bill, As for my title, blame Apple for giving it to me. I gotta admit, though,
I kinda like it better than Junior G-Man ;-)

Kurt Piersol
Senior Scientist

Usenet: {sun,...}!apple!Piersol
Internet: Piersol@apple.com
AppleLink: Piersol.k

Disclaimer: The opinions presented in this flame do not in any way 
represent the opinions of anyone, even myself whilst I was writing it.