On Tue, 20 Oct 2009 12:10:52 +0100
Alan Maguire <Alan.Maguire at Sun.COM> wrote:
> 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.
ACCEPT
> 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.
This is outside the scope of my current changes. Could you file an RFE
please?
>
> 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.
ACCEPT (I added a guard to calling nwam_value_free() which we don't
have to do but I think makes the code easier to read; we do the same
thing with free).
mph
>
> Alan
