Ryan Bloom wrote:
I would suggest not using a thread ID. They are incedibly non-portable.
Windows uses HANDLEs instead of ints.
Not exactly. Windows has both thread handles and thead IDs. Use
GetCurrentThread to get a handle, and GetCurrentThreadId to get an int.
And anyway, a hash key
On Friday 28 September 2001 10:33 am, Branko ibej wrote:
Ryan Bloom wrote:
I would suggest not using a thread ID. They are incedibly non-portable.
Windows uses HANDLEs instead of ints.
Not exactly. Windows has both thread handles and thead IDs. Use
GetCurrentThread to get a handle, and
On Wed, Sep 26, 2001 at 04:51:11PM -0700, Brian Pane wrote:
I disagree. We typically don't make APR data structures responsible
for their own memory management; rather, most things require that the
caller provide an appropriate pool, because the application can make
better choices about
On Fri, Sep 28, 2001 at 12:24:49PM -0700, Justin Erenkrantz wrote:
On Wed, Sep 26, 2001 at 04:51:11PM -0700, Brian Pane wrote:
I disagree. We typically don't make APR data structures responsible
for their own memory management; rather, most things require that the
caller provide an
On Fri, Sep 28, 2001 at 12:34:37PM -0700, Aaron Bannert wrote:
This is what I was alluding to in my absurdly vague message early on in
this thread. What I failed to realize at the time was that we don't have
a good way of getting that pool/freelist pointer deep into our filter
APIs. Am I
On Fri, 28 Sep 2001, Justin Erenkrantz wrote:
On Fri, Sep 28, 2001 at 12:34:37PM -0700, Aaron Bannert wrote:
This is what I was alluding to in my absurdly vague message early on in
this thread. What I failed to realize at the time was that we don't have
a good way of getting that
On Wed, 26 Sep 2001, Brian Pane wrote:
The fact that we implement any type of freelist
shouldn't be exposed externally outside of the bucket code - it
should remain hidden. I think the external API to the buckets
must remain the same.
I disagree. We typically don't make APR data
Okay, I've been thinking about this a lot today. I think I've come up
with a better design for this freelist scheme. The problem with the
current scheme is that it's very implementation specific... for example,
changing from SMS to the pass-in-an-int-list-number scheme required
changing the
On Wed, Sep 26, 2001 at 12:05:33AM -0400, Cliff Woolley wrote:
Okay, I've been thinking about this a lot today. I think I've come up
with a better design for this freelist scheme. The problem with the
current scheme is that it's very implementation specific... for example,
changing from
On Wed, Sep 26, 2001 at 12:03:55AM -0700, Justin Erenkrantz wrote:
...
Something strikes me as incorrect with this. First, it'd require
initialization of this code per thread and then they'd have to store
it globally so that all of the code that calls _bucket_foo_create()
can pass it - but
Justin Erenkrantz wrote:
[...]
What's wrong with an internal hashtable here keyed off of the
thread id (or whatever is returned by apr_os_thread_current)?
Internally, you can represent the apr_bucket_freelist* as you
describe (that sounds good) - so we can abstract all of that
away, but forcing
On Wed, 26 Sep 2001, Brian Pane wrote:
How about just adding an apr_bucket_freelist* to the conn_rec
and requiring each MPM to set it appropriately? Filters could
then reach the right free list via the ap_filter_t*, and most
other callbacks could reach it through the request_rec*, without
On Wednesday 26 September 2001 01:00 am, Greg Stein wrote:
On Wed, Sep 26, 2001 at 12:03:55AM -0700, Justin Erenkrantz wrote:
What's wrong with an internal hashtable here keyed off of the
thread id (or whatever is returned by apr_os_thread_current)?
Internally, you can represent the
On Wed, 26 Sep 2001, Ryan Bloom wrote:
Because this can all be easily accomplished with the connection ID
field that is already in the conn_rec.
Well, then how's about we let Apache do the static array of
apr_bucket_freelist*'s and use the connection ID to index into that?
That way we keep the
On Wed, 26 Sep 2001, Ryan Bloom wrote:
That's fine.
Will I get lynched if I further suggest putting this thing in the
scoreboard? We've got our conn_rec-id that gives us a handy lookup into
the scoreboard, so it seems a logical place to put it. Or it can just be
a separate array, though the
On Wednesday 26 September 2001 10:13 am, Cliff Woolley wrote:
On Wed, 26 Sep 2001, Ryan Bloom wrote:
That's fine.
Will I get lynched if I further suggest putting this thing in the
scoreboard? We've got our conn_rec-id that gives us a handy lookup into
the scoreboard, so it seems a logical
On Wed, 26 Sep 2001, Ryan Bloom wrote:
Will I get lynched if I further suggest putting this thing in the
scoreboard? We've got our conn_rec-id that gives us a handy lookup into
the scoreboard, so it seems a logical place to put it. Or it can just be
a separate array, though the
On Wednesday 26 September 2001 11:42 am, Cliff Woolley wrote:
On Wed, 26 Sep 2001, Ryan Bloom wrote:
Will I get lynched if I further suggest putting this thing in the
scoreboard? We've got our conn_rec-id that gives us a handy lookup
into the scoreboard, so it seems a logical place to
On Wed, Sep 26, 2001 at 02:42:14PM -0400, Cliff Woolley wrote:
bit alone might disqualify it.) Oh well, it wouldn't kill us to have a
static array in each MPM that's the appropriate size and to just use that,
indexed by the second half of AP_CHILD_THREAD_FROM_ID. As long as they
get stored
On Wed, 26 Sep 2001, Justin Erenkrantz wrote:
[I'll respond to the rest of this later, I'm late for class]
apr_bucket_get_my_freelist()
{
#if APR_HAS_THREADS
apr_os_thread_t tid = apr_os_thread_current();
for all elements in the internal linked-list
search for free-list
On Wednesday 26 September 2001 12:21 pm, Justin Erenkrantz wrote:
On Wed, Sep 26, 2001 at 02:42:14PM -0400, Cliff Woolley wrote:
bit alone might disqualify it.) Oh well, it wouldn't kill us to have a
static array in each MPM that's the appropriate size and to just use
that, indexed by the
On Wed, Sep 26, 2001 at 01:43:42PM -0700, Ryan Bloom wrote:
You can keep saying to use the thread ID, but it won't work. Not all
platforms use an int to reference a thread_id. We have a opaque
data type for threads for a reason. At least two of our platforms today
do not refer to
22 matches
Mail list logo
