5ms MAX_IDLE_WAIT in xi_rpc::next_read leads to unwanted CPU utilization

[kennylevinsen]

xi_rpc::next_read currently implements naïve busy-polling to service multiple task sources in a non-blocking manner. This is done by attempting to read from the peer with a very short timeout, and if the timeout is met, try to service other "background tasks".

A more appropriate implementation would either be a proper poll that blocks indefinitely on all sources, or something along the lines of an mpsc select! across multiple channels.

On an ultrabook idling at 800MHz, a busypoll with 5ms timeout leads to ~1% reported CPU utilization, which is a lot for doing nothing.

[cmyr]

Xi is not under active development, so I wouldn't expect this to be fixed in the near future, but I agree that this is an inelegant aspect of the design.

[kennylevinsen]

Indeed. In this case it was discovered due to the use of Xi components in lapce.

[cmyr]

ah gotcha, I do need to look into that project in more detail, I have aspirations for having a better text-editing component in druid.