On Tue, Feb 23, 2010 at 6:02 AM, Robert Story <rst...@freesnmp.com> wrote:
> 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.
>
Handling alarms via SIGALRM was already broken by r16831 (
http://net-snmp.svn.sourceforge.net/viewvc/net-snmp?view=rev&revision=16831).
In that revision a helper thread was added in
agent/mibgroup/if-mib/data_access/interface_linux.c. Because no provisions
are taken in snmpd to restrict delivery of SIGALRM to a certain thread,
SIGALRM can be delivered to either the main agent thread or the helper
thread. If SIGALRM is delivered to the prefix listener helper thread, the
invocation of run_alarms() from the SIGALRM handler will trigger several
data races and may even cause a crash.
Anyway, I have reverted r18000 (see also
http://net-snmp.svn.sourceforge.net/viewvc/net-snmp?view=rev&revision=18000
and
http://net-snmp.svn.sourceforge.net/viewvc/net-snmp?view=rev&revision=18192
).
Bart.
------------------------------------------------------------------------------
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
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
