NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/sys/isis/372

Text File | 1993-01-12 | 5.0 KB | 108 lines

Newsgroups: comp.sys.isis
Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!batcomputer!cornell!glade
From: [e-mail] (Bradford Glade)
Subject: Re:  Question about isis and C++
Message-ID: <[e-mail]>
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Tue, 12 Jan 1993 15:36:38 GMT
Lines: 98

  In article <[e-mail]> [e-mail] writes:
  >I am trying to use isis from a C++ program and I'm having a problem :
  >
  >When I call :
  >
  >        isis_entry(QUERY_ENTRY, (void (*) (message*))cback_receive_query,
  >                                                    "cback_receive_query");
  >
  >        I would like to send an extra parameter to the
  >        "cback_receive_query"
  >        callback function, namely the "this" pointer.
  >
  >        I can do it successfully with the "isis_mainloop" call, but
  >        not with the
  >        "isis_entry". isis_mainloop expects a (void (*) (void *)) callback
  >        parameter, instead of a (void (*) (message*)) as isis_entry does.
  >
  >Could anyone help me solving this problem ?


While this won't help you today, the next academic release of the Isis
system (with the Horus kernel) will directly support this type of use.
Each thread in Horus takes two arguments, an environment pointer,
which is typically defined by the same code that declares the thread,
and an argument pointer which is defined by the code that spawns the
thread.  In practice, both of these arguments tend to be pointers to
structures containing many fields.  For instance, the environment
pointer may contain file descriptors for the output streams that the
thread should use, etc. The argument pointer for upcalls in Horus
typically take an event structure, which among other fields includes a
field for a message.  This is how messages get delivered from Horus.
So in your situation you would either supply the "this" pointer as the
environment, or would make it a field in a structure that you supply
as an argument to the upcall (callback).

  From Ken:
  >This is a common complaint about Isis from C++...  Most
  >C++ users (we have plenty of them) specify a straight C function for
  >these callbacks, and then have that function demultiplex incoming
  >messages by passing them to the correct object instance.  Normally,
  >this involved including enough information at the front of each messaghe
  >to figure which object(s) will need to see the message.

In addition the release should include some support for remote method
invocation and object naming.  While the shape of the interface is
still to be determined, the tool will be responsible for the
demultiplexing of messages to their corresponding objects, and for
triggering methods upon message delivery.  The tool will also provide
support for object migration and will make use of the state transfer
facility in the VSync library (which sits above the Horus kernel).

  From Ken:
  >This points to another limitation.  If you try and think of individual
  >objects as members of groups, instead of thinking of the process in which
  >they live as the group member, you might have one object try to become a
  >client of a group G, while two others try and join G and yet another
  >decides to leave G.

  >This is because the objects in a C++ system tend not to know about
  >each other and so if an object class includes code to join,leave or
  >call pg_client, each separate instance will try to do that, possibly
  >on the same group.

  >But, Isis doesn't let one address space -- one heavyweight program --
  >belong to a group multiple times.  Olof Hagsand did a nice paper on
  >this with Holger Herzog, Robert Cooper and I when visiting.  He
  >can send a copy (email: [e-mail]).  So, you need to avoid such
  >behavior, and this says that individual object instances should
  >normally not join and leave groups directly, unless you have a different
  >group for each object instance.

  >Brad Glade has been working on a new kind of "lighweight" object interface
  >for Isis that would work much better.  Perhaps he could post something
  >about this to the newsgroup -- Brad?

The Horus kernel and the VSync library support what are known as
lightweight groups.  These are intended, in part, to solve the problem
that Ken mentions above.  Lightweight groups will allow you to
associate a single group with each object that you create.  In this
manner the object can behave independently and not worry about the
other objects that share its address space.  The lightweight group
layer of the VSync library manages these groups so that they make
efficient use of the basic groups provided by the Horus kernel.  This
layer is in turn used by the object support tools as a transport for
message passing and for object naming.  I'll post more on the
interface to the lightweight group layer as it solidifies.

-Brad.





--
Bradford B. Glade             |  [e-mail]
Dept. of Computer Science     |  Tel. [phone] (Office)
314 Upson Hall Cornell Univ.  |  FAX  [phone] (CS Dept.)
Ithaca, NY 14853              |