Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!cimshop!davidm
From: davidm@cimshop.UUCP (David Masterson)
Newsgroups: comp.lang.c++
Subject: Re: Objectifying incoming messages?
Keywords: Messages
Message-ID: <452@cimshop.UUCP>
Date: 2 Aug 89 23:11:47 GMT
References: <444@cimshop.UUCP>
Organization: Consilium Mt. View CA
Lines: 64
In-reply-to: davidm@cimshop.UUCP's message of 26 Jul 89 17:17:08 GMT

In a previous message,

	I talked about the mechanics of changing general messages into
specific objects in order to turn a bit-stream (say, from a network) into a
known object.  Most seem to feel that it is the responsibility of an object to
write itself out and read itself back in (construct itself).  Obviously, the
message processor (disk reader) has to get clues from the bit-stream as to
what type of object is coming in and, therefore, switch to the appropriate
object construction mechanism.  The problem is that this leads to
inefficiencies because of the need to move bits around more than once in order
to get it into a usable form (move bits to a buffer, determine object type,
construct object type, and move bits into constructed area).  An implication
has been that there are well-known ways of dealing with such things in C that
C++ does not handle as well.

	Perhaps, there is a need to define what types of data are capable of
being written out of a program and (by implication) what types of data can be
read into a program.  Since an object is represented by its data and methods
and methods are of no use outside a process (cannot be written out), maybe it
is better to not define external data as an object (at least in C++).  An
object can be constructed to contain this external data, but the data itself
is not an object (therefore, no virtual function pointers, esoteric object
types, etc.).  Therefore, anything passing between C++ programs (via shared
memory, messages, disk files, databases, etc.) can only be data structures.
Many people would say that this is obvious, but others might not.  What I'm
looking for is to see if people agree with this formalization of definition
and its implications for understanding the problem.

	Now that I've made that point, let me jump back into message passing
in a multitasking system and my main question.  Let's assume a situation in
order to clarify the problem.  In a system where a number of processes may be
communicating with each other via interprocess messages, a single process can
not make an assumption as to what message is coming in.  Therefore, the
message processor will have to read the message, look for clues as to what
type of message it is, and have it processed in the appropriate manner.  In a
C++ scenario, an object might be working on constructing itself by sending a
message to a data server and awaiting a reply.  Due to the nature of the
process, several things may be going on at the same time (like window
management), so its not appropriate for the process to hang waiting for the
reply to the data request (it might never arrive anyway).

	In C, this would be handled by having the request procedure issue the
request and return to the message processing procedure.  The reply would
eventually come back and the message procedure would give it to the reply
procedure.  However, in C++, its not a good idea for a constructor function to
return before the reply (and, therefore, the data) has been received.  Thus
the C++ program is hung.  So, my question is what is the appropriate C++
fashion for constructing an object when the object construction may involve
sending a message and getting a reply that you don't want to wait for?

	Some might suggest treating the message processor as an object and
having the constructor function call this processor when it needs a reply
message in order to complete its work.  I think this leads to a recursive
problem in that potentially many messages may have come in that led to many
objects being constructed that led to many outstanding requests.  This sounds
like a potential stack overflow problem.  If your trying to create a server of
some sort, this is not a stateless way of doing things.  There must be a
better way!

	I see I'm beginning to ramble, so I'll hold it here and see what sort
of "brilliant" ideas come in (I hope, I hope ;-).  Have a good one!

David Masterson
uunet!cimshop!davidm		or		DMasterson@cup.portal.com