apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr/threadproc/unix thread.c
Date Thu, 07 Jun 2001 02:22:18 GMT
On Wed, Jun 06, 2001 at 03:02:44PM -0400, Cliff Woolley wrote:
> On Wed, 6 Jun 2001, Justin Erenkrantz wrote:
> > On Wed, Jun 06, 2001 at 06:12:17PM -0000, dreid@apache.org wrote:
> > >   - add an apr_pool_t to the sms structure
> >
> > -1 (non-veto, but awfully close).  Uh, why are we doing this?
> > I thought that a pool would be defined in terms of a sms (not now, but
> > at some point).  This would not allow that to happen.
> > I'm still not entirely sold on the fact that sms needs locks.  I think
> > the locks can be handled at a higher level than sms (i.e. a pool).
> I was thinking the exact same thing, actually...

Me three.

I thought SMS was to be the underlying memory abstraction, and pools would
be implemented on *top* of those.

I'm not with Justin on the locking, though: I can see that an SMS would need
to use locks to protect itself. But I would recommend that we pass in an
apr_lock_t *if* an SMS should bother with locking. i.e. pass NULL if the SMS
won't need to worry about it (it will only be used from a single thread)

That implies that somebody has to alloc a lock outside, but we know that we
can do that: an SMS around malloc(), a pool around that, then a lock using
that pool. We can then pass that lock to SMS(my-custom-bugger).


Greg Stein, http://www.lyra.org/

View raw message