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