Michael Hunter wrote: > Please look at /net/coupe.eng/builds/mph/nwam1_work/webrev for: > > 11865 upgrade needs to cope with existing NIS configurations > 11978 nwamd exiting due to an assertion > 12025 core: wifi thread and destruction of object warring > > Comments appreciated. > >
ncu_phys.c: this deals with scan threads can be queued up waiting on the object lock, but perhaps we should do the same for connect threads too (ln 1512)? A number of these could queue up waiting on the ncu lock I guess. I was also wondering - should we add some simple logic to bail out of the scan thread before doing the scanconnect_entry() if gethrtime() - link->nwamd_link_wifi_last_scan_time < WIRELESS_SCAN_REQUESTED_INTERVAL_MIN (which we could #define in ncu.h as 10 seconds or something). This might be a way to deal with issues arising from a bunch of queued threads trying to do scans within seconds of one another once the lock becomes available. Probably best not to do this for connect threads, as each of these might in theory be to a different WLAN, and we could lose connection requests. libnwam_loc.c: not your change, but aren't we in danger of double-free()ing the nwam_value_t val in error cases? e.g. on ln 253 we call nwam_value_free() which will free val, but if the strdup fails we goto finish where we again nwam_value_free() it. I think we need to explicitly NULLify val after freeing on ln224, 234, 246, 254. Alan
