Hi Murali,
Thanks for commenting on this. I lost track of these patches
somehow. I agree that they look good, so I went ahead and commited
them. Thanks Phil!
-sam
On Apr 5, 2007, at 7:57 AM, Phil Carns wrote:
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
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
