Re: Btree Compare callback function - context parameter

Hi Patrick,
Looks to me like you are reinventing thread local storage (TLS). All the
platforms that I work on already have TLS, and yes TLS is an approach that
can be used in this scenario given the absence of any direct support for
this sort of thing in Berkeley DB.

BTW: There have been a couple of times where I had an idea for an
"enhancement" for Berkeley DB, but when I thought about it further I
realised why that "enhancement" had probably already been thought of and
discarded by the Sleepycat people as innapropriate for one reason or
another. I suspect the idea of passing app context through put() calls may
have similarly already been considered and discarded. Having said that, I
might think about the idea a bit more and post a follow up message on the
subject.

cheers,
mick

"Patrick Schaaf" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Michael Hollins" <[EMAIL PROTECTED]> writes:
>
> >I've been looking for a similar thing to Chad, but I'm a bit confused
about
> >how to make use of app_private.
>
> >Say I have multiple threads all using the same DB handle to refer to an
> >opened database. I don't see how I could make use of app_private so that
> >information I pass to put() would be delivered to my btCompareFn. The
> >problem being that threads performing concurrent puts would clobber each
> >others' app_private data.
>
> Hi Mick,
>
> good critique! I usually don't do threads, so it didn't occur to me.
> In such a multithreaded situation, an extra void* argument to put(),
> passed on to the comparison function, would be really handy.
>
> A possible workaround would be to associate a suitable structure
> with the DB app_private, something like this:
>
> struct app_private_thread_put_stuff {
> pthread_mutex_t manipulate_this;
> #define MAX_NR_ACTIVE_THREADS
> int nr_active_threads;
> struct {
> pthread_t thread_id;
> void *arg;
> } put_arg[MAX_NR_ACTIVE_THREADS];
> };
>
> Now, make a wrapper for put() which locks app_private->manipulate_this,
> puts the current thread's pthread_t / putarg into that array, unlocks
> the app_private->manipulate_this mutex, and then calls the real ->put().
> The compare function can then scan the put_arg[] array for its pthread_t,
> and thus find its own arg. On the way out, after ->put() returns, the
> put wrapper again locks / removes the info / unlocks.
>
> Ugly, certainly a lot of overhead compared to passing an additional
> argument on stack, but I can't see another way right now. The overhead
> should still be small compared to the possible advantage of using
> threads (if it isn't, the use of threads could be misguided in the
> first place :)
>
> best regards
>   Patrick