You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Stein <gs...@lyra.org> on 1999/10/19 00:45:16 UTC
Re: cvs commit: apache-2.0/src/lib/apr APRDesign
On 18 Oct 1999 rbb@hyperreal.org wrote:
> +APR_HAS_FEATURE
> +
> +This macro should evaluate to true if APR has this feature on this platform.
> +For example, Linux and Windows have mmap'ed files, and APR is providing an
> +interface for mmapp'ing a file. On both Linux and Windows, APR_HAS_MMAP
> +should evaluate to one, and the ap_mmap_* functions should map files into
> +memory and return the appropriate status codes.
> +
> +If your OS of choice does not have mmap'ed files, APR_HAS_MMAP should evaluate
> +to zero, and all ap_mmap_* functions should automatically return APR_ENOTIMPL.
> +The second step is a precaution. We will not break at compile time, just
> +because a programmer tried to write code that uses functions which may not be
> +there, but we will make sure the programmer knows he isn't doing anything.
Euh... isn't it safe to break the thing at compile time?
I'd hate to see the case if somebody forgets to check an error value and
builds a server that fails in mysterious ways.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-2.0/src/lib/apr APRDesign
Posted by Manoj Kasichainula <ma...@io.com>.
On Thu, Oct 21, 1999 at 07:22:05AM -0400, Ryan Bloom wrote:
> If we are going to not compile when a function is
> not supported, then we should not compile when a function is not
> supported. I don't want to create a bunch of rules about when we return
> APR_ENOTIMPL, and when we don't define the function. It's really simple.
> If the platform supports it, don't provide the function. If the platform
> doesn't support it (ie Windows) return APR_ENOTIMPL.
My idea was to allow people to write thread-safe libraries that
compile without hassle on unthreaded systems. If we don't provide stub
lock functions, then the writers of these libraries will have to
#ifdef around every lock or write stub functions of their own.
I figure that a good rule would be to add stub functions when a nop
wouldn't be harmful. But, I'm not too worked up about that; the
current situation is okay.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
Re: cvs commit: apache-2.0/src/lib/apr APRDesign
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> If a programmer tries to create a thread on an unthreaded system, the
> compile should fail. However, thread locks should still exist and be
> no-ops. Why? If mmap doesn't exist on your platform and you try to use
> it, you're hosed. But if thread locks don't exist because there are no
> threads, then your code will still work just fine.
HUH?!?!?!? When was the last time you saw a non-threaded platform that
provided thread locks? If we are going to not compile when a function is
not supported, then we should not compile when a function is not
supported. I don't want to create a bunch of rules about when we return
APR_ENOTIMPL, and when we don't define the function. It's really simple.
If the platform supports it, don't provide the function. If the platform
doesn't support it (ie Windows) return APR_ENOTIMPL.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: cvs commit: apache-2.0/src/lib/apr APRDesign
Posted by Manoj Kasichainula <ma...@io.com>.
On Wed, Oct 20, 1999 at 08:18:04AM -0400, Ryan Bloom wrote:
> 1) If we rely on compile time to determine success or failure, it
> will require a re-compile whenever APR comes out with an old feature
> on a new platform. If that is okay with you, then fine, I would
> much rather not require a re-compile if I can help it.
Changes in inline functions and macros will force a recompile anyway.
Recompiling is not a significant hardship, and it's much less of a
hassle than hunting for a bug caused by using a function that returns
ENOTIMPL.
> 2) APR does HAVE to have a consistent look across modules on the same
> platform. This means that functions that are currently no-ops (thread
> funcs on non-threaded platforms), will be changed to be non-existant.
> This severly breaks code in the prefork MPM. I don't mind breaking code,
> but this is a definite side effect.
If a programmer tries to create a thread on an unthreaded system, the
compile should fail. However, thread locks should still exist and be
no-ops. Why? If mmap doesn't exist on your platform and you try to use
it, you're hosed. But if thread locks don't exist because there are no
threads, then your code will still work just fine.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
APRDesign
Posted by Henrik Vendelbo <hv...@bluprints.com>.
I've been following the thread for a while, and thought I might give my .02 euro....
There is a balance here I believe. Generally I like the APR_ENOTIMPL approach. It
allows you to use the code to build an application expecting that all features in APR
will eventually be implemented. Using a design principle from OO, it provides a level
of encapsulation, since the user of APR should not design the application based on
knowledge about the internals or current state of functionality of APR.
On the other hand the need to check for succes codes can get out of hand. It reminds
me of the examples in the OS/2 SDK which is filled with int succes = api_call(...) if (succes==
In my experience an API where all functions may return NOT IMPLEMENTED leads to
buggy software since the programmer will not do the succes checks thoroughly. It is
also difficult to test all the possible combinations of what is implemented and what is not.
My approach would be to have a short list of API functions that may return NOT IMPLEMENTED.
Internally in APR should be a completely different matter. The utility functions used by
APR itself should always be implemented, or not available at all, resulting in a compile or link error.
\Henrik
> > I'd rather not see other platforms hampered because Windows has a run-time
> > only model. I also don't believe that a consistent, available API is a
> > proper goal -- it leads to a least-common-denominator system.
>
> I have a few thoughts about this. And it all comes down to who APR's
> users will be. Right now, they are Apache, but we really don't know who
> they will be in the end.
>
> 1) In the future, APR releases will not be tied to Apache, this is a
> given, I think. If we rely on compile time to determine success or
> failure, it will require a re-compile whenever APR comes out with an old
> feature on a new platform. If that is okay with you, then fine, I would
> much rather not require a re-compile if I can help it.
>
> 2) APR does HAVE to have a consistent look across modules on the same
> platform. This means that functions that are currently no-ops (thread
> funcs on non-threaded platforms), will be changed to be non-existant.
> This severly breaks code in the prefork MPM. I don't mind breaking code,
> but this is a definite side effect.
>
> I would rather use APR_ENOTIMPL, because it makes sense to me. If the
> rest of the group would rather use linker errors, that's fine. I'm not
> going to get to it anytime soon, because I only have two days before I go
> away for two weeks. I suggest anybody who feels strongly about this
> change it while I am gone. :)
Re: cvs commit: apache-2.0/src/lib/apr APRDesign
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
On Tue, 19 Oct 1999, Greg Stein wrote:
> Manoj replied with my exact thoughts. Ditto from me.
>
> I'd rather not see other platforms hampered because Windows has a run-time
> only model. I also don't believe that a consistent, available API is a
> proper goal -- it leads to a least-common-denominator system.
I have a few thoughts about this. And it all comes down to who APR's
users will be. Right now, they are Apache, but we really don't know who
they will be in the end.
1) In the future, APR releases will not be tied to Apache, this is a
given, I think. If we rely on compile time to determine success or
failure, it will require a re-compile whenever APR comes out with an old
feature on a new platform. If that is okay with you, then fine, I would
much rather not require a re-compile if I can help it.
2) APR does HAVE to have a consistent look across modules on the same
platform. This means that functions that are currently no-ops (thread
funcs on non-threaded platforms), will be changed to be non-existant.
This severly breaks code in the prefork MPM. I don't mind breaking code,
but this is a definite side effect.
I would rather use APR_ENOTIMPL, because it makes sense to me. If the
rest of the group would rather use linker errors, that's fine. I'm not
going to get to it anytime soon, because I only have two days before I go
away for two weeks. I suggest anybody who feels strongly about this
change it while I am gone. :)
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: cvs commit: apache-2.0/src/lib/apr APRDesign
Posted by Greg Stein <gs...@lyra.org>.
Manoj replied with my exact thoughts. Ditto from me.
I'd rather not see other platforms hampered because Windows has a run-time
only model. I also don't believe that a consistent, available API is a
proper goal -- it leads to a least-common-denominator system.
Cheers,
-g
On Tue, 19 Oct 1999, Manoj Kasichainula wrote:
>...Ryan's reply...
> Are you saying that because APR can't give helpful compile errors on
> Windows that it can't give helpful compile errors on Unix either?
> That's what it sounds like.
>
> It's great to try to fail gracefully at runtime when you can't fail at
> compile-time, like on Windows. But, for example, on Unix systems
> without mmap(), I think it's better to just not include an ap_mmap()
> function at all, so that the compile fails on platforms that don't
> support it. Compile-time errors are orders of magnitude easier to
> find than runtime errors.
>
> A reasonable goal to set is that if your program compiles on a
> platform, it's likely to work on that platform.
>
> --
> Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
>
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-2.0/src/lib/apr APRDesign
Posted by Manoj Kasichainula <ma...@io.com>.
On Tue, Oct 19, 1999 at 02:06:50PM -0400, Ryan Bloom wrote:
> I have thought about this all day, and here is my response/opinion. And I
> am not saying this is correct, but it is my opinion. I would like APR to
> look the same across all platforms. This means making some comprimises.
> Windows does some ugly things when it comes to compiling. For one thing,
> when compiling, it treats all Win32 platforms the same. If a function
> isn't on 95/98, they just return an error and keep going. Windows doesn't
> even give a #define to help this.
Are you saying that because APR can't give helpful compile errors on
Windows that it can't give helpful compile errors on Unix either?
That's what it sounds like.
It's great to try to fail gracefully at runtime when you can't fail at
compile-time, like on Windows. But, for example, on Unix systems
without mmap(), I think it's better to just not include an ap_mmap()
function at all, so that the compile fails on platforms that don't
support it. Compile-time errors are orders of magnitude easier to
find than runtime errors.
A reasonable goal to set is that if your program compiles on a
platform, it's likely to work on that platform.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
Re: cvs commit: apache-2.0/src/lib/apr APRDesign
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
On 21 Oct 1999, Ben Hyde wrote:
> > What does this accomplish? I'm sure it's something, I just can't think
> > of what that would be. :)
> Let's say the platform optionally supports conversion between
> graphic formats, but only if the user has installed, oh say
> quicktime. But we want to have APR pass thru graphic conversion
> routines and you can't know if they are there until runtime.
> It is a little lame to require that the only way to find out
> if the service is offered is to try using it.
Ahhhhhh. I see what you were going for now too. I'm not going to
implement this right away, because I'm not sure how useful it is with the
current APR stuff, but it is getting filed in the "Might be nice"
department. Of course, anybody else is free to implement it if they want
it.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: cvs commit: apache-2.0/src/lib/apr APRDesign
Posted by Ben Hyde <bh...@pobox.com>.
Manoj Kasichainula <ma...@io.com> writes:
> On Wed, Oct 20, 1999 at 09:40:24AM -0400, Ben Hyde wrote:
> > at runtime a new routine:
> >
> > int ap_feature_available(const char *feature_name);
> >
> > Which be used to determine if any of the feature's N routines are
> > usable.
>
> What does this accomplish? I'm sure it's something, I just can't think
> of what that would be. :)
I'm between jobs right now and I was making crepes - it's was pain
to make the batter, the filling, and then find out that the crepe
pans are still packed in the attic. If only I had done
ap_feature_available("crepe_pans") before I started.
Let's say the platform optionally supports conversion between
graphic formats, but only if the user has installed, oh say
quicktime. But we want to have APR pass thru graphic conversion
routines and you can't know if they are there until runtime.
It is a little lame to require that the only way to find out
if the service is offered is to try using it.
I'll admit that the try/fail design pattern v.s. the preflight/try is
unix like as discussed in "worse is better"
<http://www.jwz.org/worse-is-better.html>, so I can embrace it
too.
- ben
Re: cvs commit: apache-2.0/src/lib/apr APRDesign
Posted by Manoj Kasichainula <ma...@io.com>.
On Wed, Oct 20, 1999 at 09:40:24AM -0400, Ben Hyde wrote:
> at runtime a new routine:
>
> int ap_feature_available(const char *feature_name);
>
> Which be used to determine if any of the feature's N routines are
> usable.
What does this accomplish? I'm sure it's something, I just can't think
of what that would be. :)
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
Re: cvs commit: apache-2.0/src/lib/apr APRDesign
Posted by Ben Hyde <bh...@pobox.com>.
Ryan Bloom <rb...@raleigh.ibm.com> writes:
> I'm probably being incredibly dense here, so forgive me. It's a pretty
> stressful week for me.
My sympathy.
> Are you advocating failing at compile time, and having the feature macro?
> Or, are you advocating the feature macro and returning APR_ENOTIMPL?
> Or, are you advocating some mixture of the two options?
First I'm advocating taking the concept of "feature" and having it both
at runtime and compile time. At compile time the feature macro is
used to determine if the feature is available, and at runtime a new
routine:
int ap_feature_available(const char *feature_name);
Which be used to determine if any of the feature's N routines are
usable. Routines can return APR_ENOTIMPL, but only if the feature
they are part of is not available.
Secondly I agree with others that if a feature is known to be
unimplementible on the platform/configuration the user is compiling
for there it should be signaled at compile time and the functions and
data types of that feature should not exist.
- ben
> Sorry, I am having a hard time parsing your message.
Nothing exceptional about that :-).
- ben
Re: cvs commit: apache-2.0/src/lib/apr APRDesign
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
I'm probably being incredibly dense here, so forgive me. It's a pretty
stressful week for me.
Are you advocating failing at compile time, and having the feature macro?
Or, are you advocating the feature macro and returning APR_ENOTIMPL?
Or, are you advocating some mixture of the two options?
Sorry, I am having a hard time parsing your message.
Ryan
On 19 Oct 1999, Ben Hyde wrote:
>
> Two design patterns are getting confused here. Managing optional
> features at runtime v.s. compile time. If we know at compile time the
> functions of that feature should not exist. If we don't know until
> run time (do to optional kernel modules, dynamicly loaded subsystems,
> binaries that run on variant OS versions, etc.) then the spec of the
> function had better warn of that and returning APR_ENOTIMPL is fine.
> One typically needs both, and you need both feature macros at compile
> time and an analogous feature test routine for use at runtime.
>
> - ben
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: cvs commit: apache-2.0/src/lib/apr APRDesign
Posted by Ben Hyde <bh...@pobox.com>.
Two design patterns are getting confused here. Managing optional
features at runtime v.s. compile time. If we know at compile time the
functions of that feature should not exist. If we don't know until
run time (do to optional kernel modules, dynamicly loaded subsystems,
binaries that run on variant OS versions, etc.) then the spec of the
function had better warn of that and returning APR_ENOTIMPL is fine.
One typically needs both, and you need both feature macros at compile
time and an analogous feature test routine for use at runtime.
- ben
Re: cvs commit: apache-2.0/src/lib/apr APRDesign
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> Euh... isn't it safe to break the thing at compile time?
>
> I'd hate to see the case if somebody forgets to check an error value and
> builds a server that fails in mysterious ways.
I have thought about this all day, and here is my response/opinion. And I
am not saying this is correct, but it is my opinion. I would like APR to
look the same across all platforms. This means making some comprimises.
Windows does some ugly things when it comes to compiling. For one thing,
when compiling, it treats all Win32 platforms the same. If a function
isn't on 95/98, they just return an error and keep going. Windows doesn't
even give a #define to help this.
For this reason, non-implemented functions on all platforms are currently
returning APR_ENOTIMPL. I am also providing #defines for good, clean
code, but I would rather the code be as similar as possible across Windows
and Unix.
As an example, named pipes (I use this because I know 95/98 don't have
them). If I am on WinNT, I can call ap_create_named_pipe, and I will
actually get a pipe back. On 95/98 I get APR_ENOTIMPL. On Linux, I get a
valid pipe. On an imaginary Unix without Named Pipes, I'll get
APR_ENOTIMPL. The only difference will be that on that imaginary Unix,
I'll also have APR_HAS_NAMED_PIPES defined appropriately. I can't define
that on Win32, because at compile/configure time, I don't know where the
code will be run.
I really hope that makes sense, but if not, feel free to tear me apart. I
am leaning in this direction, but a part of me wants a REALLY GOOD reason
not to follow through with it. :)
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.