Re: ipc.pdf ... some remarks

On Thu, 20 Jun 2002, Christian Schlegel wrote:

> "ipc.pdf" proposal and because I am not yet sure that I got everything
> right I send you this email on your private account.

That's exactly what mailinglists are for :-)

> Many of the concepts described in your paper are exactly what is inside
> my communication patterns. Therefore, I assume that you are still
> compatible with my communication patterns, right ?

I describe a lower-level implementation, that should be compatible
with _any_ IPC. (If that is not the case, then something is wrong :-))
And the goal is to maybe come to a core library that many other Orocos
libraries could use...

> I however got the impression (when browsing your proposal) that you are
> concerned very much about various handlers and registering callback
> methods. Is that the same what is described in my design document on the
> various interfaces at the level of the framework user ? 

I want to describe _mechanism_ (what should be the lowest level
functionality_; your communication patterns are _policy_ (how should
one use a specific functionality).

> What I do with the communication patterns is to avoid that every
> consumer registers a callback method at the producer side because
> then you have strong dependencies between producer and consumer.

Indeed: this is a _policy_ (and one that you can defend with very good
arguments!). So, I don't want to suggest that all applications should
use all the mechanisms that I describe. On the contrary. But I tried
to describe those mechanisms that can support _any_ policy we will
need in Orocos. That might of course be a bit too ambituous, of
course:-)


> Where I got confused is
> which thread executes which part of the various handlers (section 3.2).

At the level I worked in the document, the choice (policy) about which
thread does what is not yet relevant. Everything can be in one single
thread even (we have a motion control application that does just
that); 

> If you look at my UML diagrams you can see that there is a clear
> distinction between the user thread, the communication activity etc.
> which allows you to provide various user interfaces like callbacks with
> handlers or blocking calls etc. without ever blocking communication (by
> the way that is the main issue with respect to avoiding deadlocks).

I again think this is a very defendable _policy_, which is not in
contradiction with what I describe at the mechanism level. (I think.)

> Another point is the "guard" (section 4.1.1). I use a guard at the
> producer side of an event to decide whether the event should fire. The
> guard itself belongs to the event but the parameters for its activation
> check are send by the event activation. This allows one e.g. to get an
> event if an activation specific set of parameters gets true. This is
> very convenient for events !

This is an important architectural design issue! We here in Leuven
all think that guards are to be avoided: if you need them, that is a
signal that the event object has one or more internal states, and
bringing this outside of the mediator object is not a good idea.

Can you give an example of where you need a guard?

> Boris and I sent a draft on hierarchical state machines to the mailing
> list some weeks ago. Have you looked at it ? What do you think ?

I still have to study it! Shame on me :-(

> So what I would suggest is to explicitly make clear which parts are
> design decisions at the "internal" part of the framework, which policies
> are used within communication patterns etc. and which application
> programmer policies and communication pattern interfaces result from
> those underlying models 

I couldn't agree more with you!:-) The ambition of the document was
exactly to provide such a common platform to talk about design
decisions in a terminology that is well-defined and shared by
everybody.


> (I think we are still compatible and you end up
> with the proposed interfaces of the communication patterns). If you look
> at my sources of the CORBA based implementation you can see how the
> producer / consumer (or client / server) part of the patterns commuicate
> by calling internal methods of their CORBA representations and how they
> are decoupled using condition variables. That decoupling e.g. is very
> important and can be found as policy in your proposal as well.

I fully agree.

Thanks for the fast response! (I haven't even announced the document
on the mailing list :-) But I still think this discussion is
interesting for the public.... Let me know if you don't mind if I post
these messages to the list.

Herman