Jim Jagielski wrote:
>
> On Sep 3, 2009, at 1:31 PM, Akins, Brian wrote:
>
>> On 9/3/09 10:30 AM, "Jim Jagielski" wrote:
>>
>>> But consider an independent process that wants to attach to that
>>> shared memory segment... at this point, we need a global lock that
>>> both Apache and this ind pro
On Sep 3, 2009, at 1:31 PM, Akins, Brian wrote:
On 9/3/09 10:30 AM, "Jim Jagielski" wrote:
But consider an independent process that wants to attach to that
shared memory segment... at this point, we need a global lock that
both Apache and this ind process will honor. So somehow we need to
st
On 09/03/2009 04:30 PM, Jim Jagielski wrote:
On May 15, 2009, at 3:33 PM, Chris Darroch wrote:
Joe Orton wrote:
w.r.t. locking, my take for socache was: you either duplicate the
code in every provider, or you duplicate the code in every API
consumer, so it wasn't obvious what was best. I exp
On Thu, Sep 3, 2009 at 10:31 AM, Akins, Brian wrote:
> Also, could just make external process use HTTP.
I'm seeing the idea of this pattern show up in lots of places.
It'd be nice to actually get an open source module that did it.
somewhere
On 9/3/09 10:30 AM, "Jim Jagielski" wrote:
> But consider an independent process that wants to attach to that
> shared memory segment... at this point, we need a global lock that
> both Apache and this ind process will honor. So somehow we need to
> store that lock *in* the shared memory segment,
On May 15, 2009, at 3:33 PM, Chris Darroch wrote:
Joe Orton wrote:
w.r.t. locking, my take for socache was: you either duplicate the
code in every provider, or you duplicate the code in every API
consumer, so it wasn't obvious what was best. I expected the
latter would be both simpler a
Joe Orton wrote:
w.r.t. locking, my take for socache was: you either duplicate the code
in every provider, or you duplicate the code in every API consumer, so
it wasn't obvious what was best. I expected the latter would be both
simpler and more flexible, so went for that.
It looks like Ji
On May 15, 2009, at 2:05 PM, Chris Darroch wrote:
Jim Jagielski wrote:
No +1... When do you think you might work on this? I have some cycles
today and would like to start the migration.
Thanks for tackling this ... I see much stuff going on! I fear
the time gap between idea and implementa
Jim Jagielski wrote:
No +1... When do you think you might work on this? I have some cycles
today and would like to start the migration.
Thanks for tackling this ... I see much stuff going on! I fear
the time gap between idea and implementation seems to grow ever larger
these days. I was ho
On Thu, May 14, 2009 at 04:23:22PM -0700, Chris Darroch wrote:
> However, note that any choices we make here also, I believe,
> impacts the socache API, which has identical issues around data
> consistency in multi-process/multi-thread contexts. Personally
> I'd love to see these two APIs be as
On May 15, 2009, at 10:15 AM, Jim Jagielski wrote:
I'm going to start some of this now...
This is pretty complete now... for some reason, I kept on getting
"foo is still in conflict errors" when renaming/moving files so
this took more steps that it should have...
On May 15, 2009, at 9:02 AM, Jim Jagielski wrote:
On May 14, 2009, at 7:14 PM, Chris Darroch wrote:
Jim Jagielski wrote:
Remove mod_slotmem (server/slotmem.c) and the associated
ap_slotmem_*() "wrapper" functions.
It's just an additional abstraction, agreed. I'm fine with
removing it
On May 14, 2009, at 7:14 PM, Chris Darroch wrote:
Jim Jagielski wrote:
Remove mod_slotmem (server/slotmem.c) and the associated
ap_slotmem_*() "wrapper" functions.
It's just an additional abstraction, agreed. I'm fine with removing
it
but got the impression that people *wanted* that ab
On May 14, 2009, at 7:41 PM, Chris Darroch wrote:
Jim Jagielski wrote:
On May 14, 2009, at 3:36 AM, jean-frederic clere wrote:
Yeah... when a do is done, we want to ensure that
none of the slots change since we are touching all slots.
In general, we assume that with get and put, only one t
On May 14, 2009, at 7:41 PM, Chris Darroch wrote:
Jim Jagielski wrote:
On May 14, 2009, at 3:36 AM, jean-frederic clere wrote:
Yeah... when a do is done, we want to ensure that
none of the slots change since we are touching all slots.
In general, we assume that with get and put, only one t
Jim Jagielski wrote:
On May 14, 2009, at 3:36 AM, jean-frederic clere wrote:
Yeah... when a do is done, we want to ensure that
none of the slots change since we are touching all slots.
In general, we assume that with get and put, only one thread is
touch any particular slot at one time.
W
jean-frederic clere wrote:
It would be great to pass server_rec* and apr_pool_t* arguments
to all the methods (except maybe num_slots() and slot_size()).
Some providers may need to report error messages, and to do that
they really need a server_rec*. They may also need to allocate
data from a
Jim Jagielski wrote:
At any rate, moving responsibility for locking up to the
caller level, as the socache API does, I think makes a lot of
sense. It means that a caller running in a single-process,
single-threaded context can simply choose not to add the overhead
of a global lock. Other call
Jim Jagielski wrote:
But my personal preference would be to remove it and instead
add an unsigned int flags field to ap_slotmem_provider_t, and
define some flag values, such as AP_SLOTMEM_FLAG_NOTMPSAFE = 0x0001
(read "not MP-safe") and AP_SLOTMEM_FLAG_PERSIST = 0x0002.
Again, +1 for this ch
Jim Jagielski wrote:
Remove mod_slotmem (server/slotmem.c) and the associated
ap_slotmem_*() "wrapper" functions.
It's just an additional abstraction, agreed. I'm fine with removing it
but got the impression that people *wanted* that abstraction.
jean-frederic clere wrote:
In mod_cluste
On May 14, 2009, at 3:36 AM, jean-frederic clere wrote:
It would also clear up some things I find odd at the moment;
for instance, why is there locking in the do() method but not
the put() method?
The do operates on all slots put/get only in one... May be a flag in
the create. Something l
> -Ursprüngliche Nachricht-
> Von: Jim Jagielski
> Gesendet: Donnerstag, 14. Mai 2009 14:46
> An: dev@httpd.apache.org
> Betreff: Re: slotmem API notes
>
> In general, I think that a provider should know if it is thread-safe
> or not and simply "work"
On May 14, 2009, at 12:37 AM, Chris Darroch wrote:
Hi --
So, define AP_SLOTMEM_PROVIDER_GROUP as "slotmem" and
AP_SLOTMEM_PROVIDER_VERSION as "0". Remove AP_SLOTMEM_STORAGE.
Rename mod_sharedmem to mod_slotmem_shm and mod_plainmem to
mod_slotmem_plain.
Rename ap_slotmem_storage_method to
On May 14, 2009, at 12:37 AM, Chris Darroch wrote:
Remove mod_slotmem (server/slotmem.c) and the associated
ap_slotmem_*()
"wrapper" functions. They do nothing that I can see except add an
extra
layer of complexity. I had no problems using the standard provider
interface to the slotmem
Chris Darroch wrote:
Hi --
Well, I should be working on mod_fcgid but I wanted to first
follow up on a long-ago promise to review the slotmem API by developing
a "test harness" framework and a slotmem provider that worked with
ZooKeeper as an experiment.
To that end, mod_shmap now offers a
25 matches
Mail list logo
