http://defect.opensolaris.org/bz/show_bug.cgi?id=12885
--- Comment #3 from amaguire <alan.maguire at sun.com> 2009-12-14 17:14:52 UTC --- (In reply to comment #2) > The alternative would be to simply process the state event in the context in > which it is generated (i.e. in the context in which nwamd_object_set_state() > is > called). There are complications with this, since we sometimes call state > change events without the object lock and in different thread contexts. This is ultimately the right way to go here. Reworking nwamd_object_set_state() to process the state change by calling the state machine function in the state-change-generating context does however have complications. Firstly, we need to rewrite nwamd_object_set_state() to grab the object lock and then call nwamd_object_set_state_locked(). This latter function will create an object state event, send it to external nwamd event consumers and then process it (rather than enqueuing it for later processing as we do now). Some complications: - since state change events can be enqueued for later processing (via nwamd_object_set_state_timed()), we need the state machine function (the object state event handler) to deal with both the scenario that the event was enqueued (a timed state event) or is being processed directly. The best solution here is to add an object field to the nwamd_event_t that is mostly NULL but is non-NULL for directly-processed object state events. - we need to hold the object lock throughout the object state event handling function and in the case of NCUs, in the NCU state machine function. - some state changes cause other state changes, which will result in calls to nwamd_object_set_state_locked(). In order for us then to send events in order, we need to send the event prior to processing it. This causes problems however since we fill in details (such as the parent NCP) when processing object state events, so the sent event would be incomplete. - the immediate processing of state changes may shut out other events that require processing, particularly in cases where we process a number of state changes for an object sequentially. This may reintroduce some of the nwamadm unresponsiveness noted previously (and addressed by not holding object locks for extended periods). -- Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
