On 3/1/2017 1:00 PM, Hefty, Sean wrote: >>>> I don't think that we should introduce an asych context into >> libibverbs. >>> >>> Why not? >> >> Generally, I dislike the idea of running threads from libraries, >> particularly libraries like ibverbs. So many apps get no benefit >> from the thread, but it sits there connected to udev.. > > I thought Doug was referring to reporting the device add/remove event > through some event reporting interface, like what the librdmacm > already does. So no threads for that are needed. IMO, this makes > sense. It can be done without a thread, that's not to say I would necessarily do so myself. > I didn't follow his idea for how the device list would be updated and > kept in sync between the app and the library. There is no requirement that the device list be kept in sync between the library and the app, period. There are three usages for what I suggested: 1) The app gets a device list initially just like it does now. If the app never updates that list again, so be it. This is 100% backward compatible. 2) The simplified version of hotplug/unplug that has been discussed: the app calls ibv_get_device_list. As proposed by Alex, the library would rescan the sysfs directory on this call. If the device is there, great. If it isn't, great too. Under my proposed implementation, the exact same thing is true. If the device is there, great. If there isn't a new device in the list already, then great too. Because the initial implementation proposal left if up to the app to determine how/when to check for a new device, there was never any guarantee that whatever triggered the app to look for the new device meant that it was ready to be used in sysfs and would be found by the re-reading of the sysfs directory. So whatever race might be present in my proposed implementation would also be present in the original implementation. 3) My proposed implementation where an entry point is added for async events. In this case, the library would not pass the event on up until the device was ready to be used, so there is no race here. And there is minimal delay from detection to notification and ready for use. > If you had device add/remove events, the get_event call could > intercept that event and update the device list there. But I don't > know that you try to sync a shared list between the library and the > app. No, I wouldn't try that at all. The inherently racy thing in all of this is having the library be responsible for scanning a device, but not responsible for detecting that there is a new device to be scanned. -- Doug Ledford GPG Key ID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD