Hi Walt,

> 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.

yep, that was the intent. I did not realize that doing it the way I did
would not stop new requests from showing up.
 Feel free to do anything that makes most sense then :)

>
> 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.

What you described above was what I was trying to achieve but obviously
did not :)
thanks for cleaning that up!
Murali

>
> 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

Reply via email to