Re: blocking communication?

Bob Koninckx <[email protected]>
Newsgroups gmane.science.robotics.orocos.user
Message-ID <[email protected]>
On 2002.04.24 09:34 [email protected] wrote:
> > -----Original Message-----
> > From: Herman Bruyninckx 
> [mailto:[email protected]]
> > Sent: Wednesday, April 24, 2002 9:11 AM
> > Cc: Open RObot COntrol Software
> > Subject: Re: [Orocos] blocking communication?
> >
> >
> > On Wed, 24 Apr 2002 [email protected] wrote:
> >
> > > I am a PhD student of the TU-Vienna. I followed the last
> > discussion about
> > > communication and configuration (states, interupts, ...) with high
> > > attention. For me a simple question arises:
> > > Why do you use blocking communication patterns?
> >
> > The blocking could be useful as synchronization.
> >
> > > Isn't it better to use only non-blocking communication,
> > because it enables a
> > > seperation of communication and configuration?
> >
> > Why can't one separate configuration and blocking communication?
> 
> Maybe 'configuration' (especially gerneral configuration as mentioned
> in
> Henriks answer) was the wrong term. I try to explain the
> communication-configuration-link with the following example:
> Assume a blocking query (consits of query-request & query-answer).
> When the
> query-request is already sent out, the query-request sending component
> is
> blocked (waiting for the query-answer). If the query-request sending
> component has to be reconfigured during this time it is blocked! Hence
> a



Aren't we confusing "blocking" with "busy waiting" here ? The fact that 
a
component is waiting for response in a blocking call, doesn't mean that 
it
becomes inaccessible for others (that would mean it is busy waiting), 
it just
means that the "blocking" call does not return before it has the answer 
it
needs.


Bob

> 'special' communication (=communication-configuration-link) has to be
> implemented to interrupt the blocking communication in such a
> situation.
> I got the impression that the Communication Pattern of Smartsoft
> exactly
> deals with this point.
> 
> Wolfgang
> 
> >
> > Herman
> >
> >
> > _______________________________________________
> > Orocos mailing list
> > [email protected]
> > http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos
> >
> 
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.