What is the motivation of the "posted" list? Is it to allow server
requests that are in progress to complete, but not allow any new ones to
start (since we are exiting)? If so, I think it would be much better to
stop the new requests at the point where they are "started" (which I'm
working on right now anyway). Otherwise, it would make more sense to
try to get BMI to not receive the new messages in the first place. In
neither case does freeing the s_op seem the right way to do it.
I'm doing my last conversion right now anyway, so I can implement this
easily, but I need to know what effect we're trying to get.
Walt
Murali Vilayannur wrote:
Hi walt,
Hmmm. Did it ever actually work?
I hope so.. :-)
Any reason why you think it does not work? I will fix it appropriately
then..
We had fixed a bug recently with the request scheduler that
seemed to manifest as a signal handler termination bug but that was just
fixed recently..so that was unrelated.
Well, whatever, its not going to work now. I'll see if I can figure out
a clean way to provide the functionality.
Okay; do let me know what the issues are :)
thanks,
Murali
Walt
Murali Vilayannur wrote:
Hi Walt,
server_purge_unexpected_recv_machines(void)
is that a new function? and under what circumstances is it used?
Fairly recent function. This gets called only from the signal handler for
the server and what it does is to remove any previously posted sm's
to field unexpected messages in preparation for the server to exit.
So no more new messages will be received after the server gets a signal to
terminate gracefully.
Thanks,
Murali
--
Dr. Walter B. Ligon III
Associate Professor
ECE Department
Clemson University
--
Dr. Walter B. Ligon III
Associate Professor
ECE Department
Clemson University
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
