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
values
> >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
applied
> >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,
just
> >waiting on a patch to change it. Will Rowe seems to have ideas about how
to
> >do it so maybe he'll provide a patch. I think this is something that
should
> >be in 1.0 as we'll have to live with it for a long time.
>
> I'll investigate this afternoon.

Cool.

> >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.
That
> >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
it
> >could (possibly) be done by adding another function, so maybe we can
avoid
> >the change.
>
> Seems like a reasonable request.
>
> >The other items were marked as being non-showstoppers by Justin, though
if
> >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
it,
> >while Ryan's has had a +1 vote. (Will Rowe's +1 seems vague as to which
side
> >of the fence he's on)
> >Neither has gotten near the 3 +1's required, so neither is presently
going
> >in.
>
> Ok hold up - 1.0 is in CTR :)  But in any case, I'm arguing that their
patches
> aren't mutually exclusive:
>
> rbb's:  Split the DEFAULT lock creation into an unnamed and named
behavior.
>
> 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
introduce
> 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
need
> to be deployed for 1.0 or the existing behavior maintained until 2.0
(ewww.)

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?

david


Mime
View raw message