You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2007/10/15 07:38:10 UTC
Showstoppers to apr release(?)
Here's my list of open issues which should probably be determined before
we roll out 1.2.x, I was hoping we were further along than this on Unix
in particular;
* HP/UX 11.11i testatomic.c:288 Failed creating threads??? Investigating,
it happens to be the only testatomic failure (1/17). Enabling the
concurrency, which it appears we can, has no effect.
* Solaris 10, testpoll.c:314 we are failing with only APR_POLLOUT when we
had expected both APR_POLLIN and APR_POLLOUT to be signaled. Ideas?
* HP/UX 11.11i fails in a fun way at testsockets.c:85, 100 and 127, we see
error 221 EPROTONOSUPPORT instead of 225 EAFNOSUPPORT. Very odd :)
Do we add this to APR_STATUS_IS_EAFNOSUPPORT or otherwise combine them?
* Solaris 10, testsockets.c:146 fails in an interesting way when we haven't
bound an IPv6 adapter (including ::1), it successfully binds and then
fails at 146 with ENOKEY (126)??? Clues?
* Sol, Linux, HP, Win32, testsockets:146 saw port 4242 when we expected recvfrom
to fill in port 7771 for IPv6; more fun on AIX, I'm seeing this 2x! I'm
very confused if we promise this in our API contract or should defer fixing
this until APR 1.3.0. Thoughts?
* Win32 built IPv6 without an IPv6 protocol driver, it definitely cannot parse
a mixed IPv6 dotted IP, and returns SUCCESS with a null sa. This triggers
failures (no longer faults) at testipsub:139 and testsock:227. Should we
patch to present this as some sensible error return? Is the client expected
to look out for a NULL sa? Thoughts please, see my earlier thread on the
topic, I've only learned that it's ::n.n.n.n syntaxes that die without some
help from the protocol layer.
Given how many issues we've had to correct in the past, this is overall not very
disappointing. I'll be submitting proposed proc.c flavors to trunk/ for OS2,
Netware and BEOS once I incorporate the final round of unix/proc changes to them.
Re: testshm flaw (err 2 or 22)
Posted by Jeff Trawick <tr...@gmail.com>.
On Nov 7, 2007 1:45 AM, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> William A. Rowe, Jr. wrote:
> >
> > This flaw is significant. Need a fast solution. Thoughts?
>
> My personal thought is that this is not a regression, and we should just
> go ahead, tag 1.2 and resolve it later.
+1; not a regression
this simpler testcase captures the limitation: (dunno where it
works/fails other than HP-UX)
static void test_destroy_after_remove(abts_case *tc, void *data)
{
apr_status_t rv;
apr_shm_t *shm, *shm2;
apr_shm_remove(SHARED_FILENAME, p);
rv = apr_shm_create(&shm, SHARED_SIZE, SHARED_FILENAME, p);
APR_ASSERT_SUCCESS(tc, "Error allocating shared memory block", rv);
if (rv != APR_SUCCESS) {
return;
}
ABTS_PTR_NOTNULL(tc, shm);
apr_shm_remove(SHARED_FILENAME, p);
rv = apr_shm_destroy(shm);
APR_ASSERT_SUCCESS(tc, "Error destroying shared memory block", rv);
apr_shm_t *shm, *shm2;
apr_shm_remove(SHARED_FILENAME, p);
rv = apr_shm_create(&shm, SHARED_SIZE, SHARED_FILENAME, p);
APR_ASSERT_SUCCESS(tc, "Error allocating shared memory block", rv);
if (rv != APR_SUCCESS) {
return;
}
ABTS_PTR_NOTNULL(tc, shm);
apr_shm_remove(SHARED_FILENAME, p);
rv = apr_shm_destroy(shm);
APR_ASSERT_SUCCESS(tc, "Error destroying shared memory block", rv);
}
testshm flaw (err 2 or 22)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
>
> This flaw is significant. Need a fast solution. Thoughts?
My personal thought is that this is not a regression, and we should just
go ahead, tag 1.2 and resolve it later. But I'd be looking for a couple
of ack's before doing that, since 1.2 right now is shaping up to be a quite
long-lived release, especially for unix.
Re: Showstoppers to apr release(?)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
>
> testshm failing for me with 1.2.x but not 1.2.11
> Line 254: Error destroying shared memory block (22): Invalid argument
>
> (new code added to testshm.c after 1.2.11)
>
> Maybe I can look further tonight...
Hmmm. I believe this has detected a real flaw ;-)
We need to gracefully release the now-removed shm without complaining that
we cannot find it to remove it, unless apr_shm_create -> apr_shm_remove -> release
(either pool cleanup, or apr_shm_destroy) is a completely invalid construct,
in which case this entire test was bogus initially.
But I think we want to support the behavior; we need to ensure the remove is the
very final act of apr_shm_destroy/cleanup. And decide if we should ignore the
error 2 (what I see on linux), error 22 (what you observe on hp) as part of the
cleanup, or return it to the caller and document the anomily.
My hunch is that the rv's at lines 52 and 73 of shmem/unix/shm.c should simply
be ignored. OR we can unset shm_t's filename* to NULL on shm_remove, but that
requires a careful audit that the proper cleanup procedure will still result
from the internal call to shm_cleanup_owner.
In fact - this test could have gone one step further, and proven by removing
shm before shm2 that we have messed up the unlinking of the multiple instances
of the same named resource.
This flaw is significant. Need a fast solution. Thoughts?
Bill
Re: Showstoppers to apr release(?)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
> but
>
> testshm failing for me with 1.2.x but not 1.2.11
> Line 254: Error destroying shared memory block (22): Invalid argument
>
> (new code added to testshm.c after 1.2.11)
If not easily reparable, it will be backed out.
For Joe's objection, backing out testdir change from 1.2.x branch while we
discuss at length later this week.
Otherwise essentially proceeding on plan.
Bill
Re: Showstoppers to apr release(?)
Posted by Jeff Trawick <tr...@gmail.com>.
On Nov 3, 2007 5:57 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On 11/2/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> > I'm verifying non-breakage on aix and hp pa-risc (no ia32/64 boxes around),
> > and am backporting DSO detection if I don't find a flaw in the next few hours.
>
> Then I'll skip those until we have a release candidate.
I just tried apr-1.2.x vs. apr-1.2.11 on HP-UX PA-RISC 11iv1...
compiler warnings same before and after
config detection/decisions as reflected in config.status are the same,
other than the new logic for finding STRUCT_STAT_ST_BLOCKS and
SYS_PARAM_H
but
testshm failing for me with 1.2.x but not 1.2.11
Line 254: Error destroying shared memory block (22): Invalid argument
(new code added to testshm.c after 1.2.11)
Maybe I can look further tonight...
No time to play with apr-util ATM.
Re: Showstoppers to apr release(?)
Posted by Jeff Trawick <tr...@gmail.com>.
On 11/2/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> William A. Rowe, Jr. wrote:
> >> * maybe some other issue I don't know about
> >
> > Darwin 9. It's a clusterfuck, since we picked up on sendfile, and then
> > told them ever-so-nicely we can't compile sendrecv.c. Joy :)
> >
> > So - backport my patch from trunk which demonstrates either my bug or
> > darwin's bug? Or disable sendfile detection for solaris? Or actually
> > match ifdef-for-ifdef the mess in sendfile, and disable sendfile on
> > all unimplemented platforms? /shrug - I'm growing beyond caring at this
> > point now that I recognize apple-folks couldn't be bothered to submit
> > any patches they had used.
>
> Thanks Aaron for picking this up. But I really don't want to wait a week
> to hear the semantic is right or wrong, better to simply disable the mess
> until 1.3.x
>
> >> then I'm willing to invest considerable time in the 36 hours to check
> >> for *regressions* on some AIX 5.x level and HP-UX/PA-RISC 11iv1, and
> >> report and perhaps even fix what I can find.
> >
> > While I was on the subject of Darwin, there's a lingering HPUX 11i issue
> > I wanted to address; HP's always claimed shl_load for 32-bit, but have
> > encouraged dlopen from the start for 64 bit. I believe I have a reasonable
> > test for this in trunk, my last patch to configure.in.
>
> So... for darwin, 10.5 claims it would rather have dlopen, the patch tests
> that and passes. Does someone have Darwin 8 (10.4) or earlier to validate
> that the old NS* dyld api is still being detected from configure on trunk?
I have 10.3.latest and will try that.
=> > You'll notice I shifted some platforms to avoid all the extra phooey of
> > testing for features we never use. I left os390/400/aix alone. I'm not
> > sure if you can move any of those up to the earlier "skip all the extras"
> > escape for their custom 'other' implementation? I know aix will happily
> > use dlopen().
AIX definitely must use dlopen() except ancient (somewhere around 4.2).
> I'm verifying non-breakage on aix and hp pa-risc (no ia32/64 boxes around),
> and am backporting DSO detection if I don't find a flaw in the next few hours.
Then I'll skip those until we have a release candidate.
Re: Showstoppers to apr release(?)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
>> * maybe some other issue I don't know about
>
> Darwin 9. It's a clusterfuck, since we picked up on sendfile, and then
> told them ever-so-nicely we can't compile sendrecv.c. Joy :)
>
> So - backport my patch from trunk which demonstrates either my bug or
> darwin's bug? Or disable sendfile detection for solaris? Or actually
> match ifdef-for-ifdef the mess in sendfile, and disable sendfile on
> all unimplemented platforms? /shrug - I'm growing beyond caring at this
> point now that I recognize apple-folks couldn't be bothered to submit
> any patches they had used.
Thanks Aaron for picking this up. But I really don't want to wait a week
to hear the semantic is right or wrong, better to simply disable the mess
until 1.3.x
>> then I'm willing to invest considerable time in the 36 hours to check
>> for *regressions* on some AIX 5.x level and HP-UX/PA-RISC 11iv1, and
>> report and perhaps even fix what I can find.
>
> While I was on the subject of Darwin, there's a lingering HPUX 11i issue
> I wanted to address; HP's always claimed shl_load for 32-bit, but have
> encouraged dlopen from the start for 64 bit. I believe I have a reasonable
> test for this in trunk, my last patch to configure.in.
So... for darwin, 10.5 claims it would rather have dlopen, the patch tests
that and passes. Does someone have Darwin 8 (10.4) or earlier to validate
that the old NS* dyld api is still being detected from configure on trunk?
> You'll notice I shifted some platforms to avoid all the extra phooey of
> testing for features we never use. I left os390/400/aix alone. I'm not
> sure if you can move any of those up to the earlier "skip all the extras"
> escape for their custom 'other' implementation? I know aix will happily
> use dlopen().
I'm verifying non-breakage on aix and hp pa-risc (no ia32/64 boxes around),
and am backporting DSO detection if I don't find a flaw in the next few hours.
I should have probably called out what I'm not waiting on;
* fixes to ipv6 kernel/no configured ipv6 adapter (hp/aix/win32 etc),
two weeks of silence is plenty for my patience :)
* fixes to solaris poll, since nobody but Henry (thanks!) is looking
at this, it won't have enough review to hit 1.2.12.
Bill
Re: Showstoppers to apr release(?)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
> On 10/15/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>> Here's my list of open issues which should probably be determined before
>> we roll out 1.2.x, I was hoping we were further along than this on Unix
>> in particular;
>
> Are you asking if these are regressions since the prior 1.2.x release
> (what I would call "showstopper"), or planning for these to be
> resolved before the next 1.2.x release whether or not they existed
> before (what I would call "nice to resolve, but not worth holding up
> the needed fixes")?
Well, the only thing holding me up is cleaning out every non-enhancement
bug that can be addressed reasonably. Bugzilla says we've been mostly
successful. I called out a short list of known things that I would see
fixed before I roll if anyone was actively solving them. Otherwise I
plan to roll right over them.
> If the only showstoppers for the next release are
>
> * regressions since 1.2.previous (that we developers know about, that
> are represented by bugzilla issues, or are exposed by test programs)
> * failure to correct apr's hand in application issues on Windows with
> 1.2.previous
> * maybe some other issue I don't know about
Darwin 9. It's a clusterfuck, since we picked up on sendfile, and then
told them ever-so-nicely we can't compile sendrecv.c. Joy :)
So - backport my patch from trunk which demonstrates either my bug or
darwin's bug? Or disable sendfile detection for solaris? Or actually
match ifdef-for-ifdef the mess in sendfile, and disable sendfile on
all unimplemented platforms? /shrug - I'm growing beyond caring at this
point now that I recognize apple-folks couldn't be bothered to submit
any patches they had used.
> then I'm willing to invest considerable time in the 36 hours to check
> for *regressions* on some AIX 5.x level and HP-UX/PA-RISC 11iv1, and
> report and perhaps even fix what I can find.
While I was on the subject of Darwin, there's a lingering HPUX 11i issue
I wanted to address; HP's always claimed shl_load for 32-bit, but have
encouraged dlopen from the start for 64 bit. I believe I have a reasonable
test for this in trunk, my last patch to configure.in.
You'll notice I shifted some platforms to avoid all the extra phooey of
testing for features we never use. I left os390/400/aix alone. I'm not
sure if you can move any of those up to the earlier "skip all the extras"
escape for their custom 'other' implementation? I know aix will happily
use dlopen().
> With less certain criteria (end date), I'll continue to pitch in a few
> minutes here or there when practical.
End date was two weeks ago. If someone is pursuing a must-have for 1.2.x
please holler about what you are fixing, otherwise I'm rolling by yesterday
already. But if you will take on this configure.in review, I'd very much
like to solve shl/dl detection now for 1.2.
I don't plan to invest much more energy in 1.2 (I'd quit investing much
energy in 0.9 already). So I'm not likely to RM again this year unless
something horrid comes up again, unless it's named 1.3.0 :-)
Bill
Re: Showstoppers to apr release(?)
Posted by Jeff Trawick <tr...@gmail.com>.
On 10/15/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Here's my list of open issues which should probably be determined before
> we roll out 1.2.x, I was hoping we were further along than this on Unix
> in particular;
Are you asking if these are regressions since the prior 1.2.x release
(what I would call "showstopper"), or planning for these to be
resolved before the next 1.2.x release whether or not they existed
before (what I would call "nice to resolve, but not worth holding up
the needed fixes")?
If the only showstoppers for the next release are
* regressions since 1.2.previous (that we developers know about, that
are represented by bugzilla issues, or are exposed by test programs)
* failure to correct apr's hand in application issues on Windows with
1.2.previous
* maybe some other issue I don't know about
then I'm willing to invest considerable time in the 36 hours to check
for *regressions* on some AIX 5.x level and HP-UX/PA-RISC 11iv1, and
report and perhaps even fix what I can find.
With less certain criteria (end date), I'll continue to pitch in a few
minutes here or there when practical.
Re: Showstoppers to apr release(?)
Posted by Martin Sebor <se...@roguewave.com>.
Lucian Adrian Grijincu wrote:
> On 10/30/07, Martin Sebor <se...@roguewave.com> wrote:
>> William A. Rowe, Jr. wrote:
>>> William A. Rowe, Jr. wrote:
>>>> Here's my list of open issues which should probably be determined before
>>>> we roll out 1.2.x, I was hoping we were further along than this on Unix
>>>> in particular;
>>>>
>>>> * HP/UX 11.11i testatomic.c:288 Failed creating threads???
>>>> Investigating,
>>>> it happens to be the only testatomic failure (1/17). Enabling the
>>>> concurrency, which it appears we can, has no effect.
>>> No clue yet - if anyone has a box, help is appreciated.
>> HP offers free HP-UX accounts (among other platforms) as part
>> of their TestDrive program:
>>
>> http://www.testdrive.hp.com/
>>
>
> Their systems are as bare bones as possible.
> tar doesn't support compression (well at lest not gzip).
> no libtool
> ./buildconf dies because there's no python and the telnet connections
> are despicable.
>
> You can only upload with ftp (5.8 kB/s).
When I signed up I asked their sysadmin to set up ssh. He was
quite responsive and helpful and set up both ssh and sftp. They
still work. He also set up GNU make on machines that didn't have
it. More recently, the compiler team started installing the aCC
betas on the machines and making them available to beta testers.
Maybe they'll be open to adding even more software to make the
systems even more useful -- I know they are very interested in
getting people to play there. It sure would be nice if they had
svn installed.
Martin
Re: Showstoppers to apr release(?)
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
On 10/30/07, Martin Sebor <se...@roguewave.com> wrote:
> William A. Rowe, Jr. wrote:
> > William A. Rowe, Jr. wrote:
> >> Here's my list of open issues which should probably be determined before
> >> we roll out 1.2.x, I was hoping we were further along than this on Unix
> >> in particular;
> >>
> >> * HP/UX 11.11i testatomic.c:288 Failed creating threads???
> >> Investigating,
> >> it happens to be the only testatomic failure (1/17). Enabling the
> >> concurrency, which it appears we can, has no effect.
> >
> > No clue yet - if anyone has a box, help is appreciated.
>
> HP offers free HP-UX accounts (among other platforms) as part
> of their TestDrive program:
>
> http://www.testdrive.hp.com/
>
Their systems are as bare bones as possible.
tar doesn't support compression (well at lest not gzip).
no libtool
./buildconf dies because there's no python and the telnet connections
are despicable.
You can only upload with ftp (5.8 kB/s).
--
Lucian
Re: Showstoppers to apr release(?)
Posted by Martin Sebor <se...@roguewave.com>.
William A. Rowe, Jr. wrote:
> William A. Rowe, Jr. wrote:
>> Here's my list of open issues which should probably be determined before
>> we roll out 1.2.x, I was hoping we were further along than this on Unix
>> in particular;
>>
>> * HP/UX 11.11i testatomic.c:288 Failed creating threads???
>> Investigating,
>> it happens to be the only testatomic failure (1/17). Enabling the
>> concurrency, which it appears we can, has no effect.
>
> No clue yet - if anyone has a box, help is appreciated.
HP offers free HP-UX accounts (among other platforms) as part
of their TestDrive program:
http://www.testdrive.hp.com/
Martin
Fwd: Showstoppers to apr release(?)
Posted by Henry Jen <he...@ztune.net>.
Forward to the list.
---------- Forwarded message ----------
From: Henry Jen <he...@ztune.net>
Date: Oct 30, 2007 7:59 PM
Subject: Re: Showstoppers to apr release(?)
To: "William A. Rowe, Jr." <wr...@rowe-clan.net>
>
> A better fix for Solaris, IMHO, is don't call port_associate in
> apr_pollset_add but leave it to apr_pollset_poll by putting the
> request into the add_ring. Attached patch fix get over this issue.
A second thought found this may not be a good idea. Given a thread is
blocking on apr_pollset_poll, then another thread doing a
apr_pollset_add, I suppose when the desired event for the new socket
arrived should unblock the waiting thread.
Is that understanding correct? If so, the proposed patch will fail
that scenario.
Cheers,
Henry
Re: Showstoppers to apr release(?)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> Here's my list of open issues which should probably be determined before
> we roll out 1.2.x, I was hoping we were further along than this on Unix
> in particular;
>
> * HP/UX 11.11i testatomic.c:288 Failed creating threads??? Investigating,
> it happens to be the only testatomic failure (1/17). Enabling the
> concurrency, which it appears we can, has no effect.
No clue yet - if anyone has a box, help is appreciated.
> * Solaris 10, testpoll.c:314 we are failing with only APR_POLLOUT when we
> had expected both APR_POLLIN and APR_POLLOUT to be signaled. Ideas?
Anyone care enough about solaris to investigate? Happy to provide more hints.
> * HP/UX 11.11i fails in a fun way at testsockets.c:85, 100 and 127, we see
> error 221 EPROTONOSUPPORT instead of 225 EAFNOSUPPORT. Very odd :)
> Do we add this to APR_STATUS_IS_EAFNOSUPPORT or otherwise combine them?
Feedback please? Can EPROTONOSUPPORT be added to APR_STATUS_IS_EAFNOSUPPORT?
> * Solaris 10, testsockets.c:146 fails in an interesting way when we haven't
> bound an IPv6 adapter (including ::1), it successfully binds and then
> fails at 146 with ENOKEY (126)??? Clues?
Again, anyone care enough about solaris to look at ENOKEY?
> * Sol, Linux, HP, Win32, testsockets:146 saw port 4242 when we expected recvfrom
> to fill in port 7771 for IPv6; more fun on AIX, I'm seeing this 2x! I'm
> very confused if we promise this in our API contract or should defer fixing
> this until APR 1.3.0. Thoughts?
Thanks to Joe's hints, this is cleared out.
> * Win32 built IPv6 without an IPv6 protocol driver, it definitely cannot parse
> a mixed IPv6 dotted IP, and returns SUCCESS with a null sa. This triggers
> failures (no longer faults) at testipsub:139 and testsock:227. Should we
> patch to present this as some sensible error return? Is the client expected
> to look out for a NULL sa? Thoughts please, see my earlier thread on the
> topic, I've only learned that it's ::n.n.n.n syntaxes that die without some
> help from the protocol layer.
Just pinged on this already.
Maybe presume EAFNOSUPPORT if we see "success" with not a single address?
Bill
Re: Showstoppers to apr release(?)
Posted by Jeff Trawick <tr...@gmail.com>.
On Nov 12, 2007 6:56 PM, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
> Jeff Trawick wrote:
> > Are there still showstoppers for rolling 1.2.12?
>
> Thank you for raising the question, I was spinning around talking to folks
> at AC about any issues they were aware of. It's Paul's desire to actually
> fix sendfile/darwin if the solution is obvious, and it may be (use sendfile
> but detach either hd or tr vectors). AFAICT it's otherwise ready.
>
> I simply need to understand dynamic dbd/dbm, decide that my patch to win32
> and netware was fair, or if we need 2-tiers (APR_HAVE_DBFOO, APR_BUILD_DBFOO)
> to solve the built-in or dso-loadable modules and passing provider triggers
> on the compile line.
>
> It will roll tomorrow, if only to ensure httpd has something good to work with.
Thanks!
Re: Showstoppers to apr release(?)
Posted by Davi Arnaut <da...@apache.org>.
William A. Rowe, Jr. wrote:
> Jeff Trawick wrote:
>> On Oct 15, 2007 12:38 AM, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>>> Here's my list of open issues which should probably be determined before
>>> we roll out 1.2.x, I was hoping we were further along than this on Unix
>>> in particular;
>> Are there still showstoppers for rolling 1.2.12?
>
> Thank you for raising the question, I was spinning around talking to folks
> at AC about any issues they were aware of. It's Paul's desire to actually
> fix sendfile/darwin if the solution is obvious, and it may be (use sendfile
> but detach either hd or tr vectors). AFAICT it's otherwise ready.
Here is a workaround for the broken leopard sendfile():
http://people.apache.org/~davi/workaround-broken-leopard-sendfile.patch
But, the thing is, it's still broken because it doesn't handle partial
writes.. and sendrecv.c is a mess and I also don't trust the sendfile
test either (it doesn't test with or without headers, file offset, etc).
I'm my opinion we should ship 1.2.x without sendfile support for Leopard
until we sort things out. I'm rewriting the sendfile test to be more
automated (abts suite) and cover more aspects of the API (partial
headers/trailers/files, etc) and once we are sure it works as intended
we can safely backport.
Regards,
Davi Arnaut
Re: Showstoppers to apr release(?)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
> On Oct 15, 2007 12:38 AM, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>> Here's my list of open issues which should probably be determined before
>> we roll out 1.2.x, I was hoping we were further along than this on Unix
>> in particular;
>
> Are there still showstoppers for rolling 1.2.12?
Thank you for raising the question, I was spinning around talking to folks
at AC about any issues they were aware of. It's Paul's desire to actually
fix sendfile/darwin if the solution is obvious, and it may be (use sendfile
but detach either hd or tr vectors). AFAICT it's otherwise ready.
I simply need to understand dynamic dbd/dbm, decide that my patch to win32
and netware was fair, or if we need 2-tiers (APR_HAVE_DBFOO, APR_BUILD_DBFOO)
to solve the built-in or dso-loadable modules and passing provider triggers
on the compile line.
It will roll tomorrow, if only to ensure httpd has something good to work with.
Bill
Re: Showstoppers to apr release(?)
Posted by Jeff Trawick <tr...@gmail.com>.
On Oct 15, 2007 12:38 AM, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Here's my list of open issues which should probably be determined before
> we roll out 1.2.x, I was hoping we were further along than this on Unix
> in particular;
Are there still showstoppers for rolling 1.2.12?