On Monday 17 December 2007 20:27, Robert Hailey wrote: > > On Dec 17, 2007, at 11:44 AM, Robert Hailey wrote: > > > > On Dec 17, 2007, at 11:35 AM, Florent Daigni?re wrote: > > > >> * Robert Hailey <robert at emu.freenetproject.org> [2007-12-17 > >> 11:07:55]: > >> > >> Which is sending an FNPRejectedOverload message... That's definitly > >> not > >> what we want to do in that case. > >> > >> Let's "continue" instead... see r16659
This is the correct fix. But it's not obvious why. I've put comments in to explain the situation. > >> > >> NextGen$ > > > > I'm still confused by that comment. If we continue & loop, will the > > status ever change from SUCCESS? And why is this behavior so much > > different from a SSK block? > > Ok... I've convinced myself that simply looping won't do anything > useful (as best I can tell it will just get caught on the > waitUntilStatusChange();). That's the point! There are two cases: If a transfer HAS started, we didn't pick it up in waitUntilStatusChange() due to a race condition. The correct behaviour is to go back around the loop and pick it up, do the transfer and exit. On the other hand, if a transfer has not started, we've got a bug. The correct behaviour is unclear: if it's a synchronization issue, then going round the loop again may help, but otoh if the sender has actually exited, we may get stuck forever... so I have changed it to send a RejectedOverload. So the net effect of all of this is to not fail with RejectedOverload when we get a race condition on the status vs transferStarted(). > > Apparently (in r14068) the return statement was purposefully dropped/ > moved, and the comment in question was added. I'd let Matthew decide. > Perhaps sending a failure notify is what is wanted? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071218/4a4eec63/attachment.pgp>
