apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <da...@jetnet.co.uk>
Subject Re: 1.0 progress
Date Wed, 16 Jun 2004 21:51:33 GMT
> At 06:24 PM 6/15/2004, David Reid wrote:
> >Just to keep people up to date with progress :-)
> >
> >Ben's point about the md5 code is well made and so rather than change the
> >api I think we should fix/review the code to try and make the return
> >more meaningful.
> Agreed here.
> >Nick Kew's patch for apr-util and uri's is additions to the api, so it's
> >fine for 1.1. There is also a code fix in the patch that should be
> >prior to 1.0. It'd still be good if Nick or someone else would provide a
> >test that showed the problems though :-)
> >
> >There are now enough votes in place to change the thread return types,
> >waiting on a patch to change it. Will Rowe seems to have ideas about how
> >do it so maybe he'll provide a patch. I think this is something that
> >be in 1.0 as we'll have to live with it for a long time.
> I'll investigate this afternoon.


> >The proposed change to apr_initialise is presently veto'd by Greg, though
> >there are a lot of +1's. I'm still hopeful Greg can explain his veto.
> >said there isn't a patch available yet, so I'm forced to say that this is
> >bumped to 1.1, even though it could well be an api change. I'm guessing
> >could (possibly) be done by adding another function, so maybe we can
> >the change.
> Seems like a reasonable request.
> >The other items were marked as being non-showstoppers by Justin, though
> >anyone has time a review prior to the final release might not go amiss.
> >
> >So far the only outstanding issue of any note is the locking. Justin's
> >proposed patch seems to be most in favour but hasn't had any votes for
> >while Ryan's has had a +1 vote. (Will Rowe's +1 seems vague as to which
> >of the fence he's on)
> >Neither has gotten near the 3 +1's required, so neither is presently
> >in.
> Ok hold up - 1.0 is in CTR :)  But in any case, I'm arguing that their
> aren't mutually exclusive:
> rbb's:  Split the DEFAULT lock creation into an unnamed and named
> justin's:  Point _child_init to an intialized lock structure inherited
from the
> parent process, drop the lock name from the _child_init args.  Then
> a seperate, non-overloaded _join with a named lock to connect to any
> detached process'es lock.
> I'm +1 to both of these approaches, and neither is a 1.1 point-bump, they
> to be deployed for 1.0 or the existing behavior maintained until 2.0

This seems like a nice summary. This is the only real issue now outstanding.
Justin is travelling so isn't online and Ryan seems to ahve run out of time.
Anyone who has enough familarity with both and the locking on enough
platforms (Joe? Jeff?) care to look at merging the ideas from both into one?


View raw message