Mailing-List: contact bugs-help@apr.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@apr.apache.org
From: bugzilla@apache.org
To: bugs@apr.apache.org
Subject: DO NOT REPLY [Bug 24325] apr_reslist doesn't work without threads
In-Reply-To: <bug-24325-43213@https.issues.apache.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Message-Id: <20080727011210.1402E234C17D@brutus.apache.org>
Date: Sat, 26 Jul 2008 18:12:09 -0700 (PDT)

https://issues.apache.org/bugzilla/show_bug.cgi?id=24325


--- Comment #9 from Bojan Smojver <bojan@rexursive.com>  2008-07-26 18:12:09 PST ---
> The only reason I brought up enabling apr_reslist in a non-threaded environment was to get a straight-forward interface, so the developer doesn't need to care about OS details; if no threads, apr_reslist transparently drops all the mumbo-jumbo.

That's what I've been trying to explain - in its current implementation reslist
cannot do that (and I personally don't see why it should). It is up to everyone
using reslist to provide such a thing for the other developers/users (i.e. wrap
it up with some code).

So, if you're building an app, you include apr_reslist.h, because for threaded
version of it, you'll need it. Then, inside your code, you have:

#if APR_HAS_THREADS
  do stuff with reslist
#else
  do stuff without reslist
#endif

Users or developers using your code can't tell the difference when they are
interfacing with it whether they are using reslist or not. It just works.

If we warn people about inclusion of apr_reslist.h into their code above, we
are obviously warning them incorrectly, as they used the right design pattern
in their code. No point warning them.

How about we mention in the docs that reslist can only be used with threads, so
that there is no more confusion?


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org