apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: 1.0 progress
Date Wed, 16 Jun 2004 17:18:00 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.

>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

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.)

View raw message