wangz@tlab3.cs.unc.edu (Zhenxin Wang) (06/01/91)
I am trying to figure out how to use ISIS in the environment of C++. Is there a wrapper of ISIS that provides the interface to C++ ? How to use it? What are the key design ideas of the wrapper(interface) that bridge the gap between the OBLECT_oriented C++ and the TASK_oriented ISIS? Thanks! --zhenxin wang
ken@CS.Cornell.EDU (Ken Birman) (06/01/91)
In article <4148@borg.cs.unc.edu> wangz@tlab3.cs.unc.edu (Zhenxin Wang) writes: >I am trying to figure out how to use ISIS in the environment of C++. >Is there a wrapper of ISIS that provides the interface to C++ ? How to use it? >What are the key design ideas of the wrapper(interface) that bridge the gap >between the OBLECT_oriented C++ and the TASK_oriented ISIS? > Three answers: 1) You can use ISIS from C++, in the sense of calling its procedures, with some minor effort -- the V2.1 headers have a few typos (fixed in V3.0) but basically C++ can live with them. The one restriction is that ISIS won't be able to do call-backs to methods within dynamically allocated objects, because these are internally identified by a pointer to the base plus a procedure, and most of the ISIS callbacks want the procedure to be identified by a single argument. Hacks around this: use a "static method", or callback to a standard C procedure that vectors the call to the appropriate C++ object and operation. 2) There is a C++ language, called NIGEN++, developed by a researcher who was visiting Los Alamos labs and is now at the Syracuse University CASE center, which handles a useful class of simulation and scientific computations by mapping from a sugared C++ into ISIS calls. You can find a description of this in a back posting on our comp.sys.isis archives on ftp.cs.cornell.edu (pub/comp.sys.isis) 3) Looking to the future, my group has gotten interest in doing a better integration of ISIS into C++ (and ADA, and M3, and ML...) We are probably not going to just support the current ISIS model in those languages -- the thinking is to try and understand the system as a class hierarchy and develop a new interface from these languages that has the functionality of ISIS but might look totally different. This turns out to be hard. Indeed, we would actually like to think of the structure of our new systems in terms of a layering of abstract modules and this turns out to be subtle too. I do not envision eliminating the ISIS execution model in doing this. Your question seems to imply that tasks (==threads?) and objects are somehow incompatible, if I understand the last sentence correctly, while we view these as relatively independent issues. However, it would be nice to separate threads issues out from ISIS, and also to separate the ISIS message model into an interface generation stage that might use out message library and an internal interface that would be more like iovecs. If this is what you mean, we do believe that these issues can be more orthogonal than in the current ISIS, which was designed without this in mind. A second way that I can parse your comment assumes that task==process. Under this interpretation, the answer is that we definitely want the system to become more object oriented and future releases will move in that direction. We are talking to a number of groups with an interest in object oriented system structures and I am hopeful that what we do at Cornell over the next 2 years or so will turn out to fit nicely with the major efforts in this area. However, some efforts are mostly concerned with transactional objects and I don't see us moving in that direction. In fact, I think we could even build a layer having these properties over the current ISIS system, and in the near term this may be how we approach these problems. -- Kenneth P. Birman E-mail: ken@cs.cornell.edu 4105 Upson Hall, Dept. of Computer Science TEL: 607 255-9199 (office) Cornell University Ithaca, NY 14853 (USA) FAX: 607 255-4428