[EMAIL PROTECTED] wrote on Mon, 08 Oct 2007 14:56 -0500:
> True, although my patch changes that, because the address reference
> list is accessed based on the PVFS_BMI_addr_t. The
> bmi_method_addr_reg_callback function returns a PVFS_BMI_addr_t,
> which the method is meant to store, and when it comes time to call
> bmi_method_addr_forget_callback, it passes that PVFS_BMI_addr_t it
> stored.
[..]
> Within the particular method (tcp being the one I'm looking at), the
> address is destroyed (tcp_forget_addr is called). But the address
> reference is never being removed from the reference list. In the
> case of tcp, this is a big problem (the bug in question), because tcp
> calls bmi_method_addr_reg_callback for each new connection, not just
> each new peer that connects.
Thanks for all the explanation. The crucial difference with TCP
that I wasn't grokking was that it doesn't search its own internal
peer list---it always registers each new connection.
Thus your "forget" approach seems good. Except for one aspect. Why
force the method to store the PVFS_BMI_addr_t just so it can hand it
back to BMI core, which then convers it into a struct method_addr?
Can you just pass the struct method_addr directly? If not, no big
deal.
More generally, it bugs me that both core BMI and each method must
keep separate lists of addresses. It's probably time to expose the
data structure to BMI methods so we have just one list. But this is
certainly more than you set out to do.
-- Pete
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
