If the above posted approach is the way you do not want to take, then one may do this:
1 )
Instantiate a thread with an autonomous serial port-scanner, equip this thread with a PAIR/PAIR
or PUSH/PULL
( as observed from the port scanner-thread side ) connection with the main, best using a zero or low overhead transport-class ~ inproc://
or ipc://
( tcp://
transport-class simply spends just too much overheads to deliver inter-thread signalling / messaging ). Make this scanner-thread send whatever you need over this uplink to the main, whenever you feel that appropriate.
2 )
Instantiate a thread with an autonomous nanomsg-scanner, equip this thread with a PAIR/PAIR
or PUSH/PULL
( as observed from the socket scanner-thread side ) connection with the main, best using a zero or low overhead transport-class ~ inproc://
or ipc://
. Make this scanner-thread send whatever you need over this uplink to the main, whenever you feel that appropriate.
3 )
Equip the main()
with both respective counterparties ( 2x PAIR
-s or 2x PULL
-s ), as decided in 1 ) and 2 ), and maintain this inter-thread signalling / messaging plane infrastructure up and running.
4 )
Enjoy the "comfort" of a trivial blocking call to a .poll()
in the main(){...}
( as you wished above, whereas I professionally advocate for using a non-blocking code, always ... but also recognise, but not respect, your expressed wish above to loose your own code control, during indeterministically long waiting for an unblocking event - if it ever comes )
5 )
Given a .poll()
has got some message, do a aRetCODE = nn_recv( aS, &B, aBsz, NN_DONTWAIT );
reading the respective signalled uplink from either of the scanner-threads.
6 )
Loop.