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.