Hi Pekka,<br><br>Attached is timerless code. Rather than blocking for mdelay, RAs are simply scheduled in a task queue to be sent at the correct time. Care is taken to keep someone from remotely flooding the task queue.<br>
<br>Main changes:<br>* no timers/no race conditions<br>* task queue queues up scheduled RAs (Unicast and Multicast)<br>* main loop has a 'pulse' which checks if interfaces have gone up/down and automatically revives up'ed interfaces and schedules init RA's on them.<br>
* Ignore RA checking if the RA originated locally (RFC says check RA's from "other" routers)<br><br>Minor changes:<br>* sock isn't passed to functions as it's already global<br>* adding source/dest address to logging info where interesting<br>
* removed whitespaces at the end of lines<br><br>Let me know if anything is missing so I can fix.<br><br>Thanks,<br>Reuben<br><br><div class="gmail_quote">On Wed, May 5, 2010 at 10:26 PM, Reuben Hawkins <span dir="ltr"><<a href="mailto:reubenhwk@gmail.com">reubenhwk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'll try over the next week or so to submit timerless code which honours the delay...<br>
<br>Thanks,<br><font color="#888888">Reuben<br><br></font><div class="gmail_quote"><div><div></div><div class="h5">On Wed, May 5, 2010 at 9:40 PM, Pekka Savola <span dir="ltr"><<a href="mailto:pekkas@netcore.fi" target="_blank">pekkas@netcore.fi</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5"><div>On Wed, 5 May 2010, Reuben Hawkins wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This is happening in the latest from CVS in the timer code? Can you reproduce this crash in the code I submitted which removes the<br>
timers? It seems like the timers are the source of half the problems submitted to the mailing list. I stand by removing the<br>
timers. Building a poll/select based solution will dramatically simplify the code and debugging. Please let me know what<br>
guidelines I should follow to get my code integrated into the next version...<br>
</blockquote>
<br></div>
Yes, this happens with the latest CVS. I have not tried reproducing with polling based mechanism, but I don't think it would exist there.<br>
<br>
I agree that timers are causing problems (and likely continue to do so), and we would be better off without them, or by implementing better locking when using them (anyone interested in looking at this?).<br>
<br>
In order for select/poll-based mechanism to be considered, it would need to support all MUSTs from the spec and preferably SHOULDs also. I recall there was some discussion about this late last year, e.g. relating to random delay feature.<br>
<font color="#888888">
<br>
-- <br>
Pekka Savola "You each name yourselves king, yet the<br>
Netcore Oy kingdom bleeds."<br>
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings</font><br></div></div><div class="im">--<br>
radvd-devel-l mailing list : <a href="mailto:radvd-devel-l@litech.org" target="_blank">radvd-devel-l@litech.org</a><br>
<a href="http://lists.litech.org/listinfo/radvd-devel-l" target="_blank">http://lists.litech.org/listinfo/radvd-devel-l</a><br></div></blockquote></div><br>
</blockquote></div><br>