Using both client and server interfaces as parameters Topic is solved

[aclassifier]

I am trying to use both a server and a client interface in a process. The code will be a server, and when triggered it will itself trigger another process that is a server, changing role to become a client using it.

If I build a state machine around a single select combination like
case (some_state) => get trigger-from-client to start data collection..
case (some_state) => get complete-from-server..
case (some_state) => read-request-from-client..

I get these error messages in the same mixed server/client select:

• server interface cannot select on slave function
• client interface cannot select on none slave function

Q1. Is this at all possible, or do I need channels to one of the sides? (I think yes)
Q2. If possible, may I do a select inside an outer select's case? (I think not)
Q3. I didn't find any topic about this, but is there still one?
Q4. May such an intermediate process be combinable with its server and the client that uses it? (I think not)

[infiniteimprobability]

Q1. Is this at all possible, or do I need channels to one of the sides? (I think yes)

You can use interfaces. Perhaps use a notification from the server that the client needs to initiate some communications. You can select on a notification :)
https://www.xmos.com/published/how-use- ... interfaces

Q2. If possible, may I do a select inside an outer select's case? (I think not)

Hmm - not sure. It should be possible in the architecture because a select case is just a handler for an event, which will have been triggered after a waiteu. Seems reasonable you could do this again in a case with a different set of events.. Not sure if tools support it - try it?!
Generally, a single while(1){ select{ is a good idiom. It allows optimisation of core usage by the compiler using combinable and/or distributable.

Q3. I didn't find any topic about this, but is there still one?

The interfaces section of the XMOS programming guide should be a reasonable resource..

Q4. May such an intermediate process be combinable with its server and the client that uses it? (I think not)

Yes. Or it could be distributable if it purely handled interfaces - so it will use no extra cores at all. Generally, with distributable/combinable to help, you should be able write your code with the number of tasks that makes sense, and then optimise for resource usage later.

[infiniteimprobability]

Re: Q2.

I tried it and it works, as expected.. Code is nonsensical but compiler doesn't complain and proves it's a valid construct

Code: Select all

void nested_select(void){
    timer t1, t2;

    while(1){
        select{
            case t1 :> void:
            break;

            case p1 :> void:
                select{
                    case t2 :> void:
                    break;

                    case p2 :> void:
                    break;
                }
            break;
        }
    }
}

[aclassifier]

When I realized by your reply that yes it was possible indeed, I saw that I had swapped the server and client interfaces, thus confusing the roles.

So it was'nt necessary to build a leveled state machine when the select choices might take either!

Thank you!