On Wed, Dec 22, 2010 at 4:53 AM, Mishustin Kirill
<mishus...@eltex.nsk.ru>wrote:
> 21.12.2010 23:16, Bart Van Assche wrote:
>
>> Hi Kishore,
>>
>> The issue you describe is most likely completely independent of Net-SNMP.
>>
>
> It looks like it's dependent. Code, that was working perfectly with
> Net-SNMP 5.4.2.1, after being transfered to 5.5(without a single change)
> started to have problems with threads, same as Kishore described. Threads
> just stop.
>
> That's why I still use 5.4.2.1. I'm going to try 5.6.rc1 to see if this
> issue is resolved.
>
Hi Kirill,
Sorry, but that still doesn't prove that the cause is in the Net-SNMP source
code. As an example, adding threads without using proper synchronization
constructs may introduce race conditions that do no harm with one version of
the Net-SNMP source code but are harmless with another version. Have you
already analyzed your code with a data race detector ?
Another potential booby trap when working with threads are POSIX signals.
Unless signals are blocked before any threads are created and unblocked by
the thread that will handle them, signals can be delivered to any thread.
That's another potential source of race conditions. For more information,
see also
http://pubs.opengroup.org/onlinepubs/009695399/functions/sigprocmask.html.
Bart.
------------------------------------------------------------------------------
Forrester recently released a report on the Return on Investment (ROI) of
Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even
within 7 months. Over 3 million businesses have gone Google with Google Apps:
an online email calendar, and document program that's accessible from your
browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
