Don't loop on EWOULDBLOCK.
I think we can deal with any fallout. There might be none.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Mar 26 2015
Mar 26 2015
jah updated the diff for D2140: Attempt to fix race conditions and improve flexibility of iic(4), fix locking in iicbus_request_bus() and iicbus_release_bus().
jah added a comment to D2140: Attempt to fix race conditions and improve flexibility of iic(4), fix locking in iicbus_request_bus() and iicbus_release_bus().
I agree with most of your changes (and thank you for tackling this), but maybe it is time to get rid of the busy loop on EWOULDBLOCK case.
EWOULDBLOCK could only happen when the caller request the iicbus with IIC_DONTWAIT, wouldn't be better to just return EWOULDBLOCK in this case ?
Then the caller could deal with retrying if necessary.
I think this would also make the lock dropping on iicbus_poll() unnecessary.
What do you think ?
Mar 25 2015
Mar 25 2015
jah retitled D2140: Attempt to fix race conditions and improve flexibility of iic(4), fix locking in iicbus_request_bus() and iicbus_release_bus() from to Attempt to fix race conditions and improve flexibility of iic(4), fix locking in iicbus_request_bus() and iicbus_release_bus().