apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@rkbloom.net>
Subject Re: documented 1.0 showstoppers
Date Thu, 03 Jun 2004 11:17:18 GMT

On Thu, 3 Jun 2004, Jeff Trawick wrote:

> Who is going to do anything about these showstoppers and when?  If no action, I
> don't see why they should be considered showstoppers.

They are showstoppers because they break the library.  If they aren't
breaking the library, then they probably aren't showstoppers.  However,
just because something isn't being worked on doesn't mean it isn't a
showstopper.

>  From the STATUS file:
>
> RELEASE 1.0 SHOWSTOPPERS:
>
> * apr_global_mutex_child_init and apr_proc_mutex_child_init aren't
>    portable.	 There are a variety of problems with the locking API when it
>    is used with apr_create_proc instead of apr_fork.	 First, _child_init
>    doesn't take a lockmech_e parameter so it causes a segfault after the
>    apr_proc_create, because the proc_mutex field hasn't been initialized.
>    When the lockmech_e parameter is added, it _still_ doesn't work, because
>    some lock mechanisms expect to inherit from the parent process.  For
>    example, sys V semaphores don't have a file to open, so the child process
>    can't reaquire the lock.
>
> Certainly an interesting issue...

The damned locking API can't work portably as things stand today.  It
wasn't designed to be portable, and it was never tested in a portable
manner.  I posted a possible solution for this, but got no feedback at all
on my idea.  I don't have the time to work on this right now, but it is a
showstopper, and I am -1 on releasing with this issue in the code.

> * Flush out the test suite and make sure it passes on all platforms.
>    We currently have about 450 functions in APR and 147 tests.  That
>    means we have a large number of functions that we can't verify are
>    actually portable.  This TODO includes finishing the migration to the
>    unified test suite, and adding more tests to make the suite
>    comprehensive.
>
> If somebody wants this done, they should do it quick.  Not a reason to hold up
> 1.0 release IMO.  I'm curious to see how many people think it is a reason to
> hold up 1.0 AND are willing to make significant contributions to fulfilling the
> goal.

My reasoning is simple here.  Everytime we add a new test to the test
suite, we find a bug.  There are actually files in APR that aren't being
tested at all.  I made an effort on this, but real life contrived to take
away a lot of my time.  As I have more time, I will be contributing more
to the test suite.

Ryan


Mime
View raw message