Ideas on how to avoid starvation when there is multiple connections competing for a delay pool in the generic comm loop framework is welcome.
Currently the comm loops take an overly simplistic view of delay pools, and simply kicks all deferred connections alive once per second to have them react on delay pools being filled up. But not too unexpectedly this leads to a situation where some connections easily get starved. In the old comm loops (still used for poll/select) delayed connections is dealt with separately, randomizing their order. Regards Henrik
signature.asc
Description: Detta är en digitalt signerad meddelandedel
