http://defect.opensolaris.org/bz/show_bug.cgi?id=12885
Michael Hunter <michael.hunter at sun.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |michael.hunter at sun.com
--- Comment #4 from Michael Hunter <michael.hunter at sun.com> 2009-12-16
00:01:27 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
[...]
> - 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.
The nwamd_object_set_state_timed() is only used to restart the state machine
for wifi reconnect. If keeping around the nwamd_object_set_state_timed()
machinery is difficult I think a more direct mechanism can be used to effect
this retry.
>
> - 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.
We would anyways. How is this a complications? In fact we should be holding
the lock for a shorter total period of time. In the past we would do something
like
lock
decision logic leading to state change
enqueue state change
unlock
....
dequeue state change
lock
effect state change
unlock
now we don't do the extra enqueue and lock steps shortening our overall lock
time.
>
> - 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 one seems important but I don't get it. In the past we would do
enqueue state change
....
dequeue state change
effect state change
enqueue other state change
....
dequeue state change
effect state change
and so on...
now should we
decide state change
effect state change
iterate state machine
decide state change
and so on...
>
> - 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).
The maximum lock time might go up but the overall time that we hold the lock
should go down (as I argue above). But I really think the time it takes us to
process these state changes is really very short (order of 1E3 cycles on a
machine do order of 1E9 cycles per sec).
--
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.
