On Mon, 21 Dec 2009 09:47:00 +0100 Bart wrote:
BVA> If I do not receive any feedback, I will apply the patch below whithin
BVA> a few days. This patch does not modify the behavior of the Net-SNMP
BVA> agent itself (snmpd). It only modifies the behavior of applications
BVA> linked with libnetsnmp and that set NETSNMP_DS_LIB_ALARM_DONT_USE_SIG
BVA> to zero -- for these applications alarm handlers will be called from
BVA> inside agent_check_and_process() instead of from the context of
BVA> SIGALRM. Applications that set NETSNMP_DS_LIB_ALARM_DONT_USE_SIG to
BVA> zero and that did not call run_alarms() (either directly or indirectly
BVA> via agent_check_and_process()) will have to be updated -- an explicit
BVA> call to run_alarms() will have to be inserted in the socket processing
BVA> loop. Enabling SIGALRM based alarm handling by directly calling
BVA> set_an_alarm() remains possible.

I'm surprised that this didn't elicit some discussion. Since it does break
backwards compatibilty, I think we need and explicit discussion to say that
this is ok.  It seems to me that we should document the issue and leave the
code as is. Especially given that it's not even the default case. Maybe we
could add a warning when the DS value is set.  And if we do want to remove
this option, then I think the route dictated by policy is to add the warning
but don't change the code for the next release (5.6), and then the could could
actually be changed/removed in 5.7.



------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to