remote/client: no block in async console, loop even on unavailable resource

[Bastian-Krause]

Description
labgrid-client console --loop should keep trying to connect to the console even if the serial port is currently unvailable.
The console method is declared async because it needs to handle crossbar communication with the coordinator concurrently, see [1] (e.g. place kicks, resouces becoming available).

Until now it only tries again if microcom comes back with a return code != 0. But in case the resource is unavailable, labgrid bails out early because target.get_resource() raises a NoResourceFoundError.

Calling target.get_resource() waits until the resources are available by default. This is done in a blocking poll()/time.sleep() loop until a timeout is reached allowing no crossbar communication in the meantime. This again means changes in resource availability we wait for cannot arrive. So there is no point in waiting for them at all.

Fix that by awaiting the NetworkSerialPort resource while allowing other tasks to run when --loop is given. Afterwards "wait" for the NetworkSerialPort for 0 seconds. This either succeeds or a NoResourceFoundError is raised, both happens instantly. To make this work, instant Timeout(0.0) is now allowed.

[1] 19757a1 ("remote/client: close console connection on place release")

Checklist

• Documentation for the feature
• Tests for the feature
• CHANGES.rst has been updated
• PR has been tested

Fixes #926

[codecov]

Codecov Report

Merging #935 (d7ac4bb) into master (1d1cecb) will decrease coverage by 0.0%.
The diff coverage is 20.0%.

❗ Current head d7ac4bb differs from pull request most recent head 2230536. Consider uploading reports for the commit 2230536 to get more accurate results

@@           Coverage Diff            @@
##           master    #935     +/-   ##
========================================
- Coverage    56.8%   56.7%   -0.1%     
========================================
  Files         149     149             
  Lines       11091   11097      +6     
========================================
  Hits         6301    6301             
- Misses       4790    4796      +6     

Impacted Files	Coverage Δ
labgrid/remote/client.py	45.1% <11.1%> (-0.2%)	⬇️
labgrid/util/timeout.py	100.0% <100.0%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1d1cecb...2230536. Read the comment docs.

[khilman]

Tested-by: Kevin Hilman khilman@baylibre.com

[Bastian-Krause]

We've stumbled upon blocking code called from async code. So let's not merge this yet, I'll come back with another version later.

[Bastian-Krause]

The blocking wait for the NetworkSerialPort should now be fixed. labgrid-client console will now wait for 10 seconds and actually detect if the resource became available in the meantime. With --loop it will wait indefinitely until the resource becomes available. If the resource is available, it will start microcom within 0.1 seconds (so we should not miss too much output).

@khilman Please test :)

[Bastian-Krause]

Fixed s/labgrid/remote/ in the commit's subject line.

[khilman]

I tested this, and it works OK the first time (e.g. if board is powered off when console --loop is run, and then powered on after console --loop has been started.)

However, if the board is then powered off, then console --loop exits with

Got EOF from port
connection lost
labgrid-client: error: Not all resources are available: {NetworkSerialPort(target=Target(name='am335x-icev2', env=None), name='USBSerialPort', state=<BindingState.bound: 1>, avail=False, host='nuc-1', port=None, speed=115200, protocol='rfc2217')}
This may be caused by disconnected exporter or wrong match entries.
You can use the 'show' command to review all matching resources.

Ideally, console --loop should continue to loop waiting for the serial port to appear again instead of exit.