Thinking about using notification events instead of the messages
themselves...
If I use D-BUS or ZeroMQ, I get a socket descriptor. I don't want to
block on this descriptor, my application is likely blocking in
odp_schedule() or polling some queues. I could allocate an event (of
whatever type) and associate that with the socket descriptor. When the
socket can read or written, the event will be enqueued on some queue
(also specified). My application will receive the notification event and
will perform all message operations on the non-blocking socket. When no
more messages to read or message write would block, the application
re-registers the event and queue.
The only API we would need is:
void odp_notification_register(int sd, odp_event_t evt, odp_queue_t queue);
Perhaps also a call to unregister the notification, to be used at
termination.
This would be a nice and generic design (not only for this specific use
case). But it also seems limited to e.g. Linux and similar operating
systems. What about other operating environments (e.g. bare metal)?
Would those environments not implement this API? Can we have an ODP API
which only is implemented on some platforms/environments?
Why not using standard odp_queue_enq() then?
I mean, you could create a thread which spin over recv() and enqueue an
event with the received message to your queue. In that case your
datapath threads would just have to deal with queues the usual way.
And this pattern would work with the current API and for any
notification mechanism, socket, ZeroMQ, POSIX signals.
Any thoughts?
ben
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
