[AGENT++] Single-threaded build under autoconf

[Frank Fock]

Hi Ralph,

Is the whole agent single threaded then? Otherwise,
single threaded AGENT++ will not help much, because you
will get locking/cocnurrent access issues in the instrumentation
anyway.

The _NO_THREADS flag still works. You can override it in the
generated .h file.

Nevertheless, I will try to fix the autoconf opions to work
consistently between SNMP++ and AGENT++ for the next
releases.

Best regards,
Frank


Am 28.08.2014 00:18, schrieb Ralph Siemsen:
> Hi Frank,
>
> I'm using single-threaded as a quick fix for locking problems
> in code that I have inherited. I spent a week with valgrind
> trying to fix the locks (in our code, not snmp++/agent++),
> but ended up going in circles. Unfortunately I do not have
> time to rewrite the whole thing.
>
> Also, we are running this on a small embedded system with
> a single CPU core. Here threads do not really help, in fact
> the extra system calls for mutexes, and context switches,
> actually reduce performance somewhat.
>
> Any thoughts about agent++ single-threading? With the older
> versions (before autotools) the _NO_THREAD option was picked
> up from the snmp++ configuration. But with autotools that does
> not seem to work anymore.
>
> Cheers,
> -Ralph
>
> On Wed, Aug 27, 2014 at 10:54:09PM +0200, Frank Fock wrote:
>> Hi Ralph,
>>
>> First of all, many thanks for reporting those issues. They will be fixed
>> with the next release. However, the IPX support will be dropped
>> (also from the configuration) as I do not think that anybody is using
>> that anymore. The MAC address support needs to be reorganized
>> to be independent of the obsolete code, because there some users
>> that need it.
>>
>> Second, why do you need to compile a single threaded agent?
>>
>> Best regards,
>> Frank
>>
>>
>> Am 27.08.2014 22:42, schrieb Ralph Siemsen:
>>> I'm trying to build snmp++-3.3.4 without thread support.
>>>
>>>   ./configure --disable-threads
>>>
>>> This results in a syntax error in the generated config_snmp_pp.h.
>>>
>>> snmp++-3.3.4/include/snmp_pp/config_snmp_pp.h:79:5: error: #if with no expression
>>>
>>> 79:  #if
>>> 80:  #define HAVE_PTHREAD 1
>>> 81:  #endif
>>>
>>> It looks like the root cause is in configure.ac, when threads are disabled,
>>> then WITH_THREADS=0 is set, but WITH_PTHREAD variable remains undefined,
>>> which causes the generated header file to be invalid.
>>>
>>> The following patch to configure.ac seems to fix it:
>>>
>>> --- snmp++-3.3.4/configure.ac   2014-01-24 08:30:38.000000000 -0500
>>> +++ snmp++-3.3.4.new/configure.ac       2014-08-27 10:14:55.914449056 -0400
>>> @@ -186,7 +186,7 @@
>>>           ],
>>>           [])
>>>       ])
>>> -], [WITH_THREADS=0]) # endif : --enable-threads
>>> +], [WITH_THREADS=0;WITH_PTHREAD=0]) # endif : --enable-threads
>>>   dnl Checks for libraries.
>>>
>>> You may of course prefer to format that a little more clearly, I just
>>> packed it all on the same line to minimize the noise in the diff.
>>>
>>> ~~~~~
>>>
>>> Also in the same configure.ac, the MacAddress / IpxAddress options look
>>> suspiciously incorrect. Running configure --help shows:
>>>
>>>    --enable-macaddress     enable support of class MacAddress (default: off)
>>>    --disable-macaddress    disable support of class MacAddress
>>>    --enable-macaddress     enable support of class IpxAddress (default: off)
>>>    --disable-macaddress    disable support of class IpxAddress
>>>
>>> The names of the options for IpxAddress seem to be duplicates? I do not use
>>> these options, but noticed it while fixing the first problem.
>>>
>>> ~~~~~
>>>
>>> Lastly, I am also trying to build single-threaded version of agent++-4.0.2.
>>> There is no --disable-threads option in its configure script, but it does
>>> check for pthread support on non-win32 systems. This causes the compile to
>>> be done with gcc -pthread option, regardless of how snmp++ has been built.
>>>
>>> I was able to get it working by ripping out the pthread section from the
>>> configure.ac script, but that clearly is not a good solution. Would you
>>> have a suggestion on how best to handle this?
>>>
>>> Thanks,
>>> -Ralph
>>>
>>> _______________________________________________
>>> AGENTPP mailing list
>>> AGENTPP at agentpp.org
>>> https://oosnmp.net/mailman/listinfo/agentpp
>> -- 
>> ---
>> AGENT++
>> Maximilian-Kolbe-Str. 10
>> 73257 Koengen, Germany
>> https://agentpp.com
>> Phone: +49 7024 8688230
>> Fax:   +49 7024 8688231
>>
>> _______________________________________________
>> AGENTPP mailing list
>> AGENTPP at agentpp.org
>> https://oosnmp.net/mailman/listinfo/agentpp
> _______________________________________________
> AGENTPP mailing list
> AGENTPP at agentpp.org
> https://oosnmp.net/mailman/listinfo/agentpp

-- 
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax:   +49 7024 8688231