[vos-d] s5 concurrency (design part 2)

[Reed Hedges]

Peter Amstutz wrote:
> On Thu, Apr 12, 2007 at 08:16:59AM -0400, Reed Hedges wrote:
>> So messages between local objects will be serialized and passed like 
>> remote messages, rather than being method calls?   Is that overhead a 
>> concern?
> 
> It is a concern, although I'm don't think I would call it 
> "serialization" since there is no data conversion happening, it is just 
> copying the method parameters into a temporary message structure, 
> possibly copying the message if it needs to be queued, and then copying 
> those parameters out of the message structure onto the stack when we get 
> around to actually calling the method.
> 
>> If so, maybe an optimization would be to have a message format that just 
>> packs native machine format arguments into the message in the same order 
>> as the method handler arguments (omitting the field labels)?
> 
> At the moment it does still include the field labels, but the labels are 
> just pointers into the string table, so they are cheap to copy as well.


Will messages be like they are now, essentially a map? Or could we have 
a Message subclass generated from the OTD, with pointers into the 
message data for each field, so we don't have to look up fields by name 
each time?


> 
> I think it is important to retain the field labels and data types, 
> because once the message is constructed we don't know if it is going to 
> stay in process, be passed to a scripting VM or be sent out over a 
> socket.

Yeah, it would be nice not to have to do too much processing on the 
Message object to send it out over the network-- just grab a data buffer 
out of the object and byteswap it (or not).

Actually sticking to always having named fields is a good thing.  They 
tend to come in handy a lot.  (It's one slightly annoying part of 
XML-RPC in my opinion.)

One thing that would be nice in s5 is to be able to very easily nest 
message structures, either through just embedding a second message 
inside another as a field, or by a "struct definition" in the OTD and 
putting struct type data in the message.

> 
> On that note, one of the things I want to do is come up with a set of 
> rules for what to do when an incoming message has slightly different 
> parameters from the method signature of the target

Good idea.  (Other things that are also possible are to have hooks to 
"filter" and reform messages, or relay through a Vobject which does 
that.  This kind of thing will be pretty easy to do and will make it 
possible to hook together different applications.)

> 
> The rules I'm thinking of would be along the lines of:
> 
>  - "If the message has an unrecognized field tag, but all other fields 
> can be matched, ignore the unrecognized field"
>

Yes, important.

>  - "If the message fields are in a different order than the method 
> expects, reorder the message fields to match the method fields."

Yes, very very important. We shouldn't rely on the order at all really.


> 
> And so on (these are just examples off the top of my head).

same for int-float conversions.


Basically, we should expand what the Message class can do.

Here's a rough outline of how it might look:

class Message {
   size_t len; char *data; // suitable for sending over the network as is?

   string method;

   string getField(string fieldName);
   int getIntField(string fieldName);
    ///...etc...
}

Completely made up this:
<otd>
   <structdef name="struct1">
        <field required name="a" type="int" />
        <field required name="b" type="int" />
        <field required name="c" type="array(float)" />
   </structdef>
   <structdef name="point">
       <field required name="x" type="float" />
       <field required name="y" type="float" />
  </structdef>
   <message method="example-message">
     <field required name="foo" type="string" />
     <field optional name="bar" type="array(int)"></field>
     <field optional name="complex" type="struct1" />
     <field optional name="points" type="array(point)" />
  </message>
</otd>


class ExampleMessage : Message {
    typedef struct {
        int a;
        int b;
        int c;
    } struct1;
    typedef point {
        double x;
        double y;
    } point;
    char *foo;	// pointer into Message::data
    int *bar;    // pointer into Message::data. Easy to access, but need 
to use a function to insert:
    void insertIntoBar(int v);
    size_t *bar_size;  // pointer into Message::data
    struct1 *complex;
    point *points;
    size_t *points_size;
    void insertIntoPoints(ExampleMessage::point v);
};