/28/2011 04:57 AM, Neil McKee wrote:
Hi,
Here's an easy question for someone who knows their way around...
I want to maintain a new global counter, but for performance reasons I am
reluctant to use a mutex or atomic_increment to update it. I would rather
maintain a separate counter
In the mod-sflow implementation I have one thread responsible for reading in
new configuration as it changes and writing it to a shared-memory area where
the worker-processes/threads can pick it up whenever it changes. I don't know
if that is the best way or not, but it's one data point for
back.
4. make sure any critical-section logging is with APLOG_DEBUG.
http://code.google.com/p/mod-sflow/source/browse/trunk/mod_sflow.c?r=17
Neil
On Jan 9, 2011, at 11:03 PM, Neil McKee wrote:
Great feedback, thanks.
I have several questions, if you don't mind...
1. What is the most
On Jan 10, 2011, at 2:03 PM, Ben Noordhuis wrote:
On Mon, Jan 10, 2011 at 22:22, Neil McKee neil.mc...@inmon.com wrote:
I pushed changes to:
1. use PIPE_BUF from limits.h (if available).
2. use apr_file_pipe_timeout_set(pipe, 0) on both ends -- just to make
absolutely certain
is required. Do I need to bother with that, or are those
platforms obsolete anyway?
I apologize if any of these are FAQs / RTFMs. I'm new to APR.
Neil
On Jan 9, 2011, at 12:17 PM, Ben Noordhuis wrote:
On Sat, Jan 8, 2011 at 00:06, Neil McKee neil.mc...@inmon.com wrote:
This module is designed
