Well, whatever works is the right answer. :-)
Even calling tune from the work function of your block is still going to
have time ambiguity with the samples. You never know how much is
buffered in the kernel or in a gr stream.
I suppose an indirection of RPC would add some latency and possibly
exacerbate the problem. I can't say by how much.
Timed commands aside, the next safest thing you can do is shut off the
streaming (start/stop methods of the source block) if you dont want any
ambiguously tuned samples.
BTW, I just produced a PMT RPC block, code here:
https://github.com/guruofquality/grextras/blob/master/python/pmt_rpc.py
You can stick this block in a python flow graph and it will parse its
incoming messages and make calls on the flow graph. You can produce the
messages for the RPC block in python or C++ work() function.
I'm not pressuring you to use it or anything, but your inquiry did spark
a neat idea :-)
Here is a blocks coding guide I wrote for GNU Radio:
http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide
And here is the equivalent document for GrExtras:
https://github.com/guruofquality/grextras/wiki/Blocks-Coding-Guide
Looks like I left the top_block part of the guide as TODO, but here is a
good example for that:
http://gnuradio.org/cgit/gnuradio.git/tree/gr-audio/examples/c++/dial_tone.cc
-josh