httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: slotmem API notes
Date Fri, 15 May 2009 13:01:37 GMT

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 thread is
>> touch any particular slot at one time.
>
>  What about multiple processes performing a put() on the same
> slot?  It sounds like the current use case tends to be strictly
> intra-process, but the API doesn't require that, I believe.
>
>  This is why I'd either pull all the locking out and let
> the user decide (none, intra-process [thread mutexes] only,
> inter-process [global mutexes], or some custom thing).  The
> provider just doesn't know enough to be certain and we end up
> doing expensive global locking, or having to provide a Swiss
> army knife set of locking options and them implementing them
> all in each provider (slotmem and socache).  But that's just
> my two cents.
>

No, I agree it's a compelling argument... How about this as a
compromise: The create/init accepts 2 additional arguments,
a locking function pointer and an unlock function pointer.
So the end user needs to determine what sort of locking they
want when using the slotmem. The slotmem then mutexes all
access to the slots with this mutex. Additionally, each
slotmem function also accepts a flag that says "use provided
locking or force no-locking", so that even if a mutex is provided,
the end-user can decide "No, I know this is safe and so I want
to do this without any locking" for an optimization.

I think what I'm trying to avoid code that always has


	LOCK_SLOT();
	slotmem_put(.....);
	UNLOCK_SLOTOP;

All over the place... 

Mime
View raw message