Queuing commands within the supdateHook

Hello,
I have defined a Command with 2 arguments. At the first call of the
updateHook, I would like to execute (enqueue) many times the same Command
but with different parameters. I thought that the way to do this was only to
call the command many times like this :

void updateHook()
{
    myCommand(arg1, arg2);    // Command 1
    myCommand(arg3, arg4);    // Command 2
    myCommand(arg5, arg6);    // Command 3
}

The behaviour I was expecting is :

- The 3 commands are queued in the CommandProcess of the TaskContext
- The Command 1 is processed first
- The Command 2 is processed after Command1 is done.
- and so far...

The Command 1 is executed but the "done" condition is never called and the
Command 2 and Command 3 are never executed. What am I doing wrong?

Thank you,

Philippe Hamelin

Queuing commands within the supdateHook

On Tue, Jul 21, 2009 at 21:55, Philippe
Hamelin<philippe [dot] hamelin [..] ...> wrote:
> Hello,
> I have defined a Command with 2 arguments. At the first call of the
> updateHook, I would like to execute (enqueue) many times the same Command
> but with different parameters. I thought that the way to do this was only to
> call the command many times like this :
>
>

> void updateHook()
> {
>     myCommand(arg1, arg2);    // Command 1
>     myCommand(arg3, arg4);    // Command 2
>     myCommand(arg5, arg6);    // Command 3
> }
> 

That won't work and has been discussed earlier on the list (possible
on -dev). If you want to queue commands, you need to have a Command<T>
*object* for each instance. So:

void updateHook()
{
     myCommand_1(arg1, arg2);    // Command 1
     myCommand_2(arg3, arg4);    // Command 2
     myCommand_3(arg5, arg6);    // Command 3
}

.. or put them in an std::vector<Command

That's why we want 'Message' in RTT 2.0, which will have exactly the
semantics that you expected...

Peter

Queuing commands within the supdateHook

I tried this solution and now I have a different behavior: all commands are
executed simultaneously. I though that the CommandProcessor was serializing
the execution of the commands, (ie the next command is executed only if the
last one is done()). Is that true or all the sent() commands are executed at
the time?

I attached a sample program which illustrate that.

Thank you,

Philippe Hamelin

2009/7/21 Peter Soetens <peter [..] ...>

> On Tue, Jul 21, 2009 at 21:55, Philippe
> Hamelin<philippe [dot] hamelin [..] ...> wrote:
> > Hello,
> > I have defined a Command with 2 arguments. At the first call of the
> > updateHook, I would like to execute (enqueue) many times the same Command
> > but with different parameters. I thought that the way to do this was only
> to
> > call the command many times like this :
> >
> >

> > void updateHook()
> > {
> >     myCommand(arg1, arg2);    // Command 1
> >     myCommand(arg3, arg4);    // Command 2
> >     myCommand(arg5, arg6);    // Command 3
> > }
> > 

>
> That won't work and has been discussed earlier on the list (possible
> on -dev). If you want to queue commands, you need to have a Command<T>
> *object* for each instance. So:
>
>
> void updateHook()
> {
>     myCommand_1(arg1, arg2);    // Command 1
>     myCommand_2(arg3, arg4);    // Command 2
>     myCommand_3(arg5, arg6);    // Command 3
> }
> 

>
> .. or put them in an std::vector<Command >
> That's why we want 'Message' in RTT 2.0, which will have exactly the
> semantics that you expected...
>
> Peter
>

Queuing commands within the supdateHook

On Thu, Jul 23, 2009 at 21:11, Philippe
Hamelin<philippe [dot] hamelin [..] ...> wrote:
> I tried this solution and now I have a different behavior: all commands are
> executed simultaneously. I though that the CommandProcessor was serializing
> the execution of the commands, (ie the next command is executed only if the
> last one is done()). Is that true or all the sent() commands are executed at
> the time?

No, by serialisation is meant 'in the same thread'. You're confusing
the behaviour of scripting and the behaviour of the CP. The scripting
does the 'waiting until done', and then sends a new command to the CP.
The CP processes as fast as possible all incomming commands. As I
pointed out earlier, 'asynchronous message' is a better description
than 'command'.

Peter