In addition to the auxiliary's thread based implementation, the multiprocessing approach is possible too. A dedicated multiprocessing auxiliary interface is available and has the same capabilities/methods as the thread based interface.
Note
all examples are under examples/templates/mp_proxy_aux.yaml
For the moment, only the proxy auxiliary and proxy channel have their own multiprocessing version. The usage of those components only require to manipulate the flag newly created flag "processing" at connector configuration level as follow :
#__________________________ Auxiliaries section ________________________
# The multiprocessing proxy auxiliary has exactly the same interface,
# methods, or features as the thread based one. In addition, exactly
# the same configuration keywords are available.
auxiliaries:
proxy_aux:
connectors:
com: can_channel
config:
aux_list : [aux1, aux2]
activate_trace : True
trace_dir: ./suite_mp_proxy
trace_name: can_trace
activate_log :
- pykiso.lib.auxiliaries.mp_proxy_auxiliary
type: pykiso.lib.auxiliaries.mp_proxy_auxiliary:MpProxyAuxiliary
aux1:
connectors:
com: proxy_com1
type: pykiso.lib.auxiliaries.communication_auxiliary:CommunicationAuxiliary
aux2:
connectors:
com: proxy_com2
type: pykiso.lib.auxiliaries.communication_auxiliary:CommunicationAuxiliary
#__________________________ Connectors section _________________________
connectors:
proxy_com1:
config:
# when using mulitprocessing auxiliary flag processing has to True
processing : True
type: pykiso.lib.connectors.cc_mp_proxy:CCMpProxy
proxy_com2:
config:
# when using mulitprocessing auxiliary flag processing has to True
processing : True
type: pykiso.lib.connectors.cc_mp_proxy:CCMpProxy
can_channel:
config:
# when using mulitprocessing auxiliary flag processing has to True
processing : True
interface : 'pcan'
channel: 'PCAN_USBBUS1'
state: 'ACTIVE'
remote_id : 0x300
type: pykiso.lib.connectors.cc_pcan_can:CCPCanCan
#__________________________ Test Suite section _________________________
test_suite_list:
- suite_dir: suite_proc_proxy
test_filter_pattern: 'test_*.py'
test_suite_id: 2
As said before, the approach changes but the interface usage stays the same. Advanced user will not be disorientated, all methods are there. They were just adapted regarding multiprocessing pros and cons:
- lock_it
- unlock_it
- create_instance
- delete_instance
- run_command
- abort_command
- wait_and_get_report
- stop
- resume
- suspend
And inherit from the MpAuxiliaryInterface forces you to implement the following methods (as usual):
- _create_auxiliary_instance
- _delete_auxiliary_instance
- _run_command
- _abort_command
- _receive_message
So nothing really new !!
Warning
note that using multiprocessing auxiliary may lead to an adaptation of your connector implementation or your external libraries.
Logging in junit report is not supported when using multiprocesssing version of the proxy auxiliary. This means no logs from proxy auxiliary and his associated connectors (except proxy channels) will be present in junit report.
All logs coming from proxy's associated connectors (except proxy channels) won't be displayed on the console.