At least in C, it’s perfectly possible: use vl_client_connect_to_vlib_no_rx_pthread(...).
Follow the sketch in the default rx_thread_fn(..) pretty carefully. You’ll need to manually implement a non-while(1) version of vl_msg_api_queue_handler(...). Spin-waiting for replies will completely consume a CPU core. Such a spin-wait certainly requires a deadman timeout, and should do something to relinquish the cpu core. Be aware that xxx_dump API messages result in multiple replies. The standard scheme for detecting the end of such a message set is to send an echo-request message immediately after xxx_dump. When the echo-reply arrives, the preceding message set is complete. Personally, I wouldn’t go there. Vpp_api_test shows how to make the binary APIs appear to be synchronous. HTH... Dave From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Gudimetla, Leela Sankar Sent: Monday, July 30, 2018 5:19 PM To: vpp-dev@lists.fd.io Subject: [vpp-dev] Synchronous VPP-client over SHM 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 (#9977): https://lists.fd.io/g/vpp-dev/message/9977 Mute This Topic: https://lists.fd.io/mt/23864436/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
