ken@gvax.cs.cornell.edu (Ken Birman) (07/20/90)
Lately I am getting a lot of inquiries about the best way to support
applications with lots of message types, say thousands, or with some
sort of "state" associated with threads and that needs to be retained.
I think this relates to increasing use of Mach, where threads tend to
be kept around a long time, eating messages off ports -- in contrast to
the ISIS style of callbacks (we create the thread each time). I have
started to prefer the Mach style myself, and in the future we will
probably change ISIS to use this Mach style and implement the current
mechanism as a layer over it, if desired.
Meanwhile, here's what I plan to do to keep people happy... in V2.1
I am adding the following interface:
isis_entry(entry-no, MSG_ENQUEUE, "anything")
msg = msg_rcv(entry-no)
under this interface, a pre-existing task can receive messages one
at a time from a specified system entry number:
isis_entry(my_entry, MSG_ENQUEUE, "");
forever
{
msg = msg_rcv(my_entry);
msg_get(msg, "%d", &req_code);
switch(req_code)
{
case ...:
etc.
}
}
This really solves two separate problems at one time. One problem
is that ISIS really doesn't intend that you have many entry numbers
at all -- system wide, most systems would only have a small number,
perhaps one for each major class of application. The request code
in this example extends the single entry number it uses into an
arbitrary number (similarly, you could have an object-id to indicate
the object instance that should handle this request, etc.)
The second problem it solves is the .75ms overhead of creating a
task and tearing it down (>10ms in LISP!). In this example a
task hangs around indefinitely. Of course, client dumps won't be
quite as easy to interpret, but this seems like a small price to pay
(plus I can also provide a t_printable_name("name", arg) call to
say that for now, if a cl_dump is done, identify this task as name(arg))
Object oriented or C++ applications will certainly find this a much
easier interface to run through, and it may eventually be the case
that this is the base ISIS interface with isis_entry implemented over
it, if at all.
The code associated with supporting this is nearly trivial -- the only
complexity is that clib/cl_isis.c should special case MSG_ENQUEUE
handling in the same place where it special cases GENERIC_RCV_REPLY
handling now. If you are the sort of person who likes to change
someone else's code, implementing this would be a good place to start.
You can compare your solution with mine in V2.1.
Ken