Murali Vilayannur wrote:
Hi Phil,
FWIW, if these patches haven't been committed, it looks good :)
I am really backlogged with all my emails.
auto-sm-tracking.patch:
-----------------------
At some point, new linked lists were added to track state machines that
are currently running within the server. When an SM completes, it is
implicitly removed from the list. However, SMs that were started
without a request (ie internal state machines) were not added to any
list. This caused a segfault if any of these internal state machines
stopped (because the completion code assumes that all SMs should be
removed from a list). This patch corrects the problem by just making an
extra linked list for state machine instances that are not associated
with a particular request.
Just curious: why/how did the internal state machine stop? I recall
asking Sam this
question when I added those lists and he mentioned that they shouldn't
stop unless the server was being terminated. The only place where I
thought the sm structure was being removed from the list was in
server_state_machine_complete() which is invoked on state machines
invoked via a request.
Or perhaps I misunderstood what he said :)
thanks,
Murali
Hi Murali,
I don't think that it is normal for the standard internal state machines
to stop, but there isn't any mechanism to explicitly prevent it. Both
the perf-update and job-timer state machines have transitions defined to
terminate if something bad happens. Those state functions call
server_state_machine_complete() in the usual way to clean themselves up.
We saw it happen on a different internal state machine that we were
experimenting with. We didn't expect that particular one to stop
either, but it did due to an unrelated bug. This list issue was just a
helpful thing to clean up along the way.
-Phil
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
