Leela,
> =Thanks Ole for pointing at the asynchronous events. If they work like
> interrupts, then there should not be any problem with synchronous client.
> Please let me know your thoughts.
There is a single message queue that you need to service. So a blocking request
must handle messages for events. You need to deal with the dump/details calls,
and you must drain the queue fast enough so that VPP doesn’t block. E.g. if you
enabled want_interface_events, but you only drained the queue during a blocking
call, the queue could fill in the mean time and VPP would block.
You might want to take a look at VAPI if you want to do this in C.
As in building a synchronous API on top of an asynchronous one, and use
callbacks as event handlers.
I don’t think I would recommend reimplementing this part of the client library
yourself. Use one of the existing language bindings instead.
Cheers,
Ole
>
> Thanks,
> Leela sankar
>
> From: on behalf of Ole Troan
> Date: Monday, July 30, 2018 at 3:24 PM
> To: Leela Gudimetla
> Cc: "vpp-dev@lists.fd.io"
> Subject: [**EXTERNAL**] Re: [vpp-dev] Synchronous VPP-client over SHM
>
> Hi,
>
> You can run synchronously, but then you need to find a way to deal with
> asynchronous events. Like the want_ apis. src/vpp-api/client has a knob to
> choose if you want the rx thread or not.
>
> Cheers
> Ole
>
> On 30 Jul 2018, at 23:19, Gudimetla, Leela Sankar wrote:
>
>> Hello,
>>
>> We are writing a client for VPP to configure it over the shared-memory
>> interface (similar to what VAT does).
>>
>> I see that there is a rx_thread for processing responses from the server
>> (VPP) to process the replies asynchronously.
>>
>> Do we need to use the thread? Or Can we get rid of it and process the
>> responses synchronously probably by introducing a wait if there is only one
>> request at time from the client?
>>
>> This way I can use the same request context to catch the “reply_t”
>> structure. If it works, I can have request – response in a single call and
>> return the response structure.
>>
>> Please let me know if I can get rid of the rx_thread and handle this
>> synchronously.
>>
>> Thanks,
>> Leela sankar
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>>
>> View/Reply Online (#9975): https://lists.fd.io/g/vpp-dev/message/9975
>> Mute This Topic: https://lists.fd.io/mt/23864436/675193
>> Group Owner: vpp-dev+ow...@lists.fd.io
>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [otr...@employees.org]
>> -=-=-=-=-=-=-=-=-=-=-=-
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#9990): https://lists.fd.io/g/vpp-dev/message/9990
> Mute This Topic: https://lists.fd.io/mt/23923763/675193
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [otr...@employees.org]
> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9997): https://lists.fd.io/g/vpp-dev/message/9997
Mute This Topic: https://lists.fd.io/mt/23923763/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
