irsend should atomically set the transmission channel and send IR codes

[Tom M. <tme...@gm...>]

Consider a scenario of a channel change script, lets say Perl, that
executes:

irsend set_transmitters $channel
irsend SEND_ONCE $remote $keys

and at the top of the hour the application wants to change channels on
two tuners. It may launch one instance of the channel change script,
wait for it to terminate, then launch a 2nd instance. It also may spawn
children for each and run them in parallel. In which case you might end
up with the following sequence of irsend commands, where the first
channel change child is PID=1000 and the 2nd is PID=2000:

irsend set_transmitters 1 (ran from PID=1000)
irsend set_transmitters 2 (ran from PID=2000)
irsend SEND_ONCE MotorolaDTA100-PaceDC50X KEY_2 KEY_5 KEY_ENTER (ran
from PID=1000)
irsend SEND_ONCE MotorolaDTA100-PaceDC50X KEY_3 KEY_2 KEY_ENTER (ran
from PID=2000)

The result of this is that both sets of IR sequences get sent to emitter
#2.

Most channel change scripts I've seen make no attempt to mitigate this
problem, but I have seen at least one that uses a lock file as a
semaphore to prevent overlapping sequences.

This raises the question: why was irsend designed such that
set_transmitters is a separate sub-command, mutually exclusive with
SEND_ONCE?

It would make more sense had the syntax been something like:

irsend --set_transmitters=$emitter SEND_ONCE $remote $keys


 -Tom