remove the last use of notifyOnDisconnect, in server selection #1975

New Issue

zooko · 2013-05-22T23:40:11Z

zooko commented

2013-05-22 23:40:11 +00:00

Please read the description of #816 for context. There is, I believe, a bug in foolscap's notifyOnDisconnect. We only use it in one place now, which is in the share allocation algorithm's server selection. We might want to keep using it there, even though it is buggy, because it doesn't matter that much whether it works or not -- it just changes the order of shares. Or we might want to remove the use of it, for similar reasons. It would also be possible to make the server selection more complicated in order to order the shares nicely even when a server fails to accept the share that you originally intended for it, but that might not be worth the complexity cost.

Please read the description of #816 for context. There is, I believe, a bug in foolscap's `notifyOnDisconnect`. We only use it in one place now, which is in the share allocation algorithm's server selection. We might want to keep using it there, even though it is buggy, because it doesn't matter that much whether it works or not -- it just changes the order of shares. Or we might want to remove the use of it, for similar reasons. It would also be possible to make the server selection more complicated in order to order the shares nicely even when a server fails to accept the share that you originally intended for it, but that might not be worth the complexity cost.

zooko added the

labels 2013-05-22 23:40:11 +00:00

zooko added this to the undecided milestone 2013-05-22 23:40:11 +00:00

daira commented

2013-05-23 03:12:53 +00:00

I think that it's possible to retain the deterministic allocation without too much complexity. We should consider this when designing the changes to share allocation for #1130, #1382, and related tickets.

zooko commented

2013-07-09 15:46:29 +00:00

Please see comment:89020.

Please see [comment:89020](/tahoe-lafs/trac-2024-07-25/issues/1768#issuecomment-89020).

zooko commented

2015-08-25 17:34:25 +00:00

I would still like to kill our reliance on the notifyOnDisconnect feature of Foolscap, which is actually buggy in practice (see comment:89020), and which cannot be made bug-free even in principle, and which we don't really need very much.

I would still like to kill our reliance on the `notifyOnDisconnect` feature of Foolscap, which is *actually* buggy in practice (see [comment:89020](/tahoe-lafs/trac-2024-07-25/issues/1768#issuecomment-89020)), and which cannot be made bug-free even in principle, and which we don't really need very much.