You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ro...@locus.apache.org on 2000/06/01 08:59:31 UTC
cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
ronald 00/05/31 23:59:31
Modified: src/modules/standard mod_auth_digest.c
Log:
don't include apr_shmem.h when APR_HAS_SHARED_MEMORY is false, but instead set up our own dummies
Revision Changes Path
1.18 +37 -1 apache-2.0/src/modules/standard/mod_auth_digest.c
Index: mod_auth_digest.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/modules/standard/mod_auth_digest.c,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- mod_auth_digest.c 2000/05/29 08:57:18 1.17
+++ mod_auth_digest.c 2000/06/01 06:59:31 1.18
@@ -113,8 +113,44 @@
#include "ap_base64.h"
#include "apr_time.h"
#include "apr_errno.h"
-#include "apr_shmem.h"
#include "apr_lock.h"
+
+
+#if APR_HAS_SHARED_MEMORY
+#include "apr_shmem.h"
+#else
+/* just provide dummies - the code does run-time checks anyway */
+typedef void ap_shmem_t;
+typedef void ap_shm_name_t;
+
+ap_status_t ap_shm_init(ap_shmem_t **m, ap_size_t reqsize, const char *file, ap_pool_t *cont) {
+ return APR_ENOTIMPL;
+}
+ap_status_t ap_shm_destroy(ap_shmem_t *m) {
+ return APR_ENOTIMPL;
+}
+void *ap_shm_malloc(ap_shmem_t *c, ap_size_t reqsize) {
+ return NULL;
+}
+void *ap_shm_calloc(ap_shmem_t *shared, ap_size_t size) {
+ return NULL;
+}
+ap_status_t ap_shm_free(ap_shmem_t *shared, void *free) {
+ return APR_ENOTIMPL;
+}
+ap_status_t ap_get_shm_name(ap_shmem_t *c, ap_shm_name_t **name) {
+ return APR_ENOTIMPL;
+}
+ap_status_t ap_set_shm_name(ap_shmem_t *c, ap_shm_name_t *name) {
+ return APR_ENOTIMPL;
+}
+ap_status_t ap_open_shmem(ap_shmem_t *c) {
+ return APR_ENOTIMPL;
+}
+ap_status_t ap_shm_avail(ap_shmem_t *c, ap_size_t *avail) {
+ return APR_ENOTIMPL;
+}
+#endif
/* struct to hold the configuration info */
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by Manoj Kasichainula <ma...@io.com>.
On Fri, Jun 02, 2000 at 09:09:28AM -0700, rbb@covalent.net wrote:
> > OK, how about an apr_notimpl.h that provides these macros? Then the
> > developer can choose.
>
> YUCK! There are currently 9 feature macros in APR, each of these has say
> five or six functions. Now, with apr_notimpl.h, which is included in some
> places but not in others in the same program(!), we have about 45
> definitions that will sometimes allow things to compile and sometimes
> not. So, our new goal is to thoroughly confuse developers. :-)
Heh. OK, I'm not a big fan of it either; I mentioned it as a
compromise; it's a simple way to let the developer explicitly choose
one APR behavior over another. I'm not convinced it's necessary.
> Oh, and
> I can't wait until somebody accidentally puts apr_notimpl.h into httpd.h,
> and all of the modules that didn't want it start compiling but not
> working.
Then hopefully people are reviewing the CVS commit logs and notice
that apr_notimpl.h has been added. Then we smack their hand and say
"Bad!"
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by Manoj Kasichainula <ma...@io.com>.
On Thu, Jun 01, 2000 at 06:11:03PM -0700, Greg Stein wrote:
> On Thu, 1 Jun 2000, Manoj Kasichainula wrote:
> > OK, how about an apr_notimpl.h that provides these macros? Then the
> > developer can choose.
>
> Which macros?
macros that provide stubs for unimplemented functions. These macros
simply APR_ENOTIMPL.
> There are three scenarios:
>
> 1) APR provides the functionality. Cool all around.
> 2) APR does not, I want to know at compile time. Use APR_SHARED_MEMORY.
This is where we disagree. While having the feature macro is nice, I
see no reason to require the programmer to use it.
> 3) APR does not, I want to know at run-time.
I can't think of any point where this is the case. I'd restructure
your three scenarios as:
a) APR provides the function
b) APR doesn't, and I want my code to compile successfully (because my
code know how to deal with this case)
c) APR doesn't, and I don't want my code to compile successfully
For case (c), I'm suggesting that the functions just not existing is
the best solution. For case (b), I'd suggest having the programmer
either use the feature macro or apr_notimpl.h.
> Arguably, the third scenario can always be rebuilt as (2).
OK, we agree then. :)
> I could see a case where I compile my app, upgrade the APR installed
> library, and want to run without a recompile. Is that a real case? Dunno.
Ugh! I'm iffy on the whole idea of a shared APR library, but I dislike
this for other reasons.
> If you take (2) to its logical extreme, then APR_ENOTIMPL would never
> exist.
It can be useful for cases where the APR function can do something,
but it's not as flexible on some platforms as others. This kind of
problem can only be dealt with at runtime, unfortunately.
> Personally, I favor the case where I don't have to sprinkle my app with
> #if APR_SHARED_MEMORY.
Exactly.
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by Greg Stein <gs...@lyra.org>.
On Thu, 1 Jun 2000, Manoj Kasichainula wrote:
> On Thu, Jun 01, 2000 at 05:35:02PM -0700, Greg Stein wrote:
> > On Thu, 1 Jun 2000, Manoj Kasichainula wrote:
> > > #ifndef APR_SHARED_MEMORY
> > > #define ap_shmem_malloc(x) (APR_ENOTIMPL)
> > > #endif
> >
> > IMO, these ought to be in APR.
> >
> > It has nothing to do with MPMs, and it certainly beats making everybody
> > duplicate the same darn things.
>
> The problem is that I don't think "everybody" will want this. I think
> that most modules will either require shared memory or not care about
> it. And in those cases, it's far better that the module author find
> out at compile-time that the module won't work.
>
> OK, how about an apr_notimpl.h that provides these macros? Then the
> developer can choose.
Which macros? Things like APR_SHARED_MEMORY? Sure.
There are three scenarios:
1) APR provides the functionality. Cool all around.
2) APR does not, I want to know at compile time. Use APR_SHARED_MEMORY.
3) APR does not, I want to know at run-time. Use the APR_ENOTIMPL return
value.
Arguably, the third scenario can always be rebuilt as (2).
I could see a case where I compile my app, upgrade the APR installed
library, and want to run without a recompile. Is that a real case? Dunno.
If you take (2) to its logical extreme, then APR_ENOTIMPL would never
exist.
Personally, I favor the case where I don't have to sprinkle my app with
#if APR_SHARED_MEMORY.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by rb...@covalent.net.
> > IMO, these ought to be in APR.
> >
> > It has nothing to do with MPMs, and it certainly beats making everybody
> > duplicate the same darn things.
>
> The problem is that I don't think "everybody" will want this. I think
> that most modules will either require shared memory or not care about
> it. And in those cases, it's far better that the module author find
> out at compile-time that the module won't work.
>
> OK, how about an apr_notimpl.h that provides these macros? Then the
> developer can choose.
YUCK! There are currently 9 feature macros in APR, each of these has say
five or six functions. Now, with apr_notimpl.h, which is included in some
places but not in others in the same program(!), we have about 45
definitions that will sometimes allow things to compile and sometimes
not. So, our new goal is to thoroughly confuse developers. :-) Oh, and
I can't wait until somebody accidentally puts apr_notimpl.h into httpd.h,
and all of the modules that didn't want it start compiling but not
working.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by Manoj Kasichainula <ma...@io.com>.
On Thu, Jun 01, 2000 at 05:35:02PM -0700, Greg Stein wrote:
> On Thu, 1 Jun 2000, Manoj Kasichainula wrote:
> > #ifndef APR_SHARED_MEMORY
> > #define ap_shmem_malloc(x) (APR_ENOTIMPL)
> > #endif
>
> IMO, these ought to be in APR.
>
> It has nothing to do with MPMs, and it certainly beats making everybody
> duplicate the same darn things.
The problem is that I don't think "everybody" will want this. I think
that most modules will either require shared memory or not care about
it. And in those cases, it's far better that the module author find
out at compile-time that the module won't work.
OK, how about an apr_notimpl.h that provides these macros? Then the
developer can choose.
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by rb...@covalent.net.
> > #ifndef APR_SHARED_MEMORY
> > #define ap_shmem_malloc(x) (APR_ENOTIMPL)
> > #endif
>
> IMO, these ought to be in APR.
>
> It has nothing to do with MPMs, and it certainly beats making everybody
> duplicate the same darn things.
Greg, you are one of the people who originally argued to get these
function stubs out of APR.
>Subject: Re: cvs commit: apache-2.0/src/lib/apr APRDesign
>From: Greg Stein (gstein@lyra.org)
>Date: Mon Oct 18 1999 - 18:45:16 EDT
>
>
>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.
>
>Subject: Re: cvs commit: apache-2.0/src/lib/apr APRDesign
>From: Greg Stein (gstein@lyra.org)
>Date: Tue Oct 19 1999 - 22:57:15 EDT
>
>
>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.
We had this exact same argument in October 1999, and it was decided by the
group to fail the compile if a function wasn't available. I argued
against this at the time, and the original APR didn't have this
feature. I am loathe to re-implement the APR_ENOTIMPL for all functions,
because it is likely to become and argument again in the future.
The problem here is digest authentication needing to be able to allocate
server-wide memory. APR makes this possible and even easy. Basically,
each MPM needs to implement a feature macro that says MPM_IS_MULTI_PROCESS
or not. The digest auth or the core can then implement
ap_server_wide_alloc using either ap_shm_malloc or malloc or palloc.
I am -1 for having all APR functions able to return APR_ENOTIMPL for all
of the reasons discussed last October.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by Greg Stein <gs...@lyra.org>.
On Thu, 1 Jun 2000, Manoj Kasichainula wrote:
> On Thu, Jun 01, 2000 at 11:08:32AM -0700, Life is hard, and then you die wrote:
> > Yes, yuck - I'd prefer it apr too. But less yuck than putting #if all
> > over the code. Since I want to be able to handle the failure of getting
> > shared-mem or locks gracefully (i.e. a basic set of functionality still
> > works without them) I need the run-time checks anyway.
>
> There's nothing stopping a module author who knows that he is working
> around a lack of shared memory to implement stub macros:
>
> #ifndef APR_SHARED_MEMORY
> #define ap_shmem_malloc(x) (APR_ENOTIMPL)
> #endif
IMO, these ought to be in APR.
It has nothing to do with MPMs, and it certainly beats making everybody
duplicate the same darn things.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by Manoj Kasichainula <ma...@io.com>.
On Thu, Jun 01, 2000 at 11:08:32AM -0700, Life is hard, and then you die wrote:
> Yes, yuck - I'd prefer it apr too. But less yuck than putting #if all
> over the code. Since I want to be able to handle the failure of getting
> shared-mem or locks gracefully (i.e. a basic set of functionality still
> works without them) I need the run-time checks anyway.
There's nothing stopping a module author who knows that he is working
around a lack of shared memory to implement stub macros:
#ifndef APR_SHARED_MEMORY
#define ap_shmem_malloc(x) (APR_ENOTIMPL)
#endif
I think you'd find the MPM-exported functions I suggested earlier to
be more useful than direct APR calls, though.
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by "Life is hard, and then you die" <ro...@innovation.ch>.
On Thu, Jun 01, 2000 at 07:25:11AM -0700, rbb@covalent.net wrote:
>
> We talked about this a long time ago, but I'll bring it up again because
> of this commit. When APR was first implemented, all platforms ALWAYS
> implemented all functions. If a function wasn't actually implemented, it
> returned APR_ENOTIMPL. People yelled and screamed and said the linker
> should die because it will be easier for the programmer. Now, we are
> adding back in those dummy functions in a module, yuck!
Yes, yuck - I'd prefer it apr too. But less yuck than putting #if all
over the code. Since I want to be able to handle the failure of getting
shared-mem or locks gracefully (i.e. a basic set of functionality still
works without them) I need the run-time checks anyway.
In general I prefer compile time breakage to run-time breakage, but it
really messes up the code when you have #if all over (and you have to
keep compiling twice, with and without the feature defined, to make sure
it compiles everywhere). We have APR_HAS_SHMEM for those who want a
compile time breakage, so I'd go for providing dummies. But yes, it
doesn't protect folks from forgetting about APR_HAS_SHMEM and leading
to inadvertant run-time breakage. I suppose that could be solved with
something ugly like allowing folks to define a APR_PROVIDE_SHMEM_DUMMIES
before they include apr_shmem.h - if defined and if not APR_HAS_SHMEM
then and only then provide dummies.
Cheers,
Ronald
RE: shmem on win32 (was RE: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c)
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Brian Havard [mailto:brianh@kheldar.apana.org.au]
> Sent: Friday, June 02, 2000 6:54 AM
>
> On Fri, 2 Jun 2000 20:39:44 +1000, Tim Costello wrote:
>
> >On Friday, 02 June 2000, William A. Rowe, Jr. wrote:
> >> But I'm getting past myself, and have been trying to avoid
> >> the two ongoing streams of consiousness. I'm simply trying to
> >> implement shmem on Win32, not that we need it or want it :-)
> >
> >Cool... how? I recall reading somewhere that the only way to do it
> >properly on win32 was by using memory mapped files. Anyone know a
> >better way?
>
> It's weird but can be done. You create a file mapping using
> INVALID_HANDLE_VALUE so it doesn't map to an actual file.
> Here's part of a
> named shared memory class I wrote:
It doesn't? Last time I looked the system swap/paging file was
a real file :-) That's the 'file' INVALID_HANDLE_VALUE maps to.
ergo... if you are running on 95 without a swap file at all, those
calls will die.
Re: shmem on win32 (was RE: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c)
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Fri, 2 Jun 2000 20:39:44 +1000, Tim Costello wrote:
>On Friday, 02 June 2000, William A. Rowe, Jr. wrote:
>> But I'm getting past myself, and have been trying to avoid
>> the two ongoing streams of consiousness. I'm simply trying to
>> implement shmem on Win32, not that we need it or want it :-)
>
>Cool... how? I recall reading somewhere that the only way to do it
>properly on win32 was by using memory mapped files. Anyone know a
>better way?
It's weird but can be done. You create a file mapping using
INVALID_HANDLE_VALUE so it doesn't map to an actual file. Here's part of a
named shared memory class I wrote:
#ifdef __NT__
SharedMemory::SharedMemory( char *name, int reqsize )
: lock( name )
{
size = reqsize;
sharedMem = NULL;
Creator = false;
hMapping = CreateFileMapping( INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE,
0, size, Estring("SHM_") + name );
if ( hMapping != NULL ) {
Creator = GetLastError() != ERROR_ALREADY_EXISTS;
sharedMem = MapViewOfFile( hMapping, FILE_MAP_WRITE, 0, 0, 0 );
}
}
SharedMemory::~SharedMemory()
{
if ( hMapping != INVALID_HANDLE_VALUE ) {
UnmapViewOfFile( hMapping );
CloseHandle( hMapping );
}
}
#endif
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
shmem on win32 (was RE: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c)
Posted by Tim Costello <ti...@ozemail.com.au>.
On Friday, 02 June 2000, William A. Rowe, Jr. wrote:
> But I'm getting past myself, and have been trying to avoid
> the two ongoing streams of consiousness. I'm simply trying to
> implement shmem on Win32, not that we need it or want it :-)
Cool... how? I recall reading somewhere that the only way to do it
properly on win32 was by using memory mapped files. Anyone know a
better way?
...
> But I have one question about ap_shm_ functions... do we have
> any implicit/explicit assumption that the memory in process A
> is at the same physical address as process B? This is a HUGE
> question under Win32, and probably other hybrid kernels.
>
> Of course, this implies you may NEVER have a pointer x in any
> shm_alloc'ed structure in the conventional sense. First, if
> you point at the int y in the same shm, you will find that the
> address of y jumped in process 2. You CAN use the relative
> offset of y from x to store the pointer, and that offset will
> remain the same.
I agree. From what I've read so far, I don't think it's possible
to support anything like this with memory mapped files. Relative
addresses are okay - and for what it's worth, and microsoft c
provides based pointers for this sort of job. syntax is like
int __based(pStartShMem) *pointerToSomeNumber;
Tim
RE: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by rb...@covalent.net.
> > The solution that I like best is to have the feature macro
> > which the core
> > uses to implement a server_wide allocation function, using
> > either palloc
> > or malloc or ap_shm_malloc depending on the context and MPM.
>
> I don't believe palloc/malloc map well to shm. But show us
> otherwise if you like.
malloc/free:
ap_shm_init --> void (no-op)
ap_shm_destroy --> void (no-op)
ap_shm_malloc --> malloc
ap_shm_calloc --> calloc
ap_shm_free --> free
ap_get_shm_name --> return NULL, because this is anonymous memory
ap_set_shm_name --> void, anonymous shared memory
ap_open_shmem --> void (no-op) we don't have a child process
ap_shm_avail --> figure out how much system memory is
available. Have no clue how to do this on Windows.
ap_palloc:
ap_shm_init --> ap_initialize
ap_shm_destroy --> ap_terminate
ap_shm_malloc --> ap_palloc
ap_shm_calloc --> ap_pcalloc
ap_shm_free --> register cleanup
ap_get_shm_name --> return NULL, because this is anonymous memory
ap_set_shm_name --> void, anonymous shared memory
ap_open_shmem --> void (no-op) we don't have a child process
ap_shm_avail --> There is a function but I can't remember it right
now.
available. Have no clue how to do this on Windows.
The thought process maps better to malloc/free than ap_palloc IMHO though.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Friday, June 02, 2000 11:22 AM
>
> > > I'm with Ryan on this. The ap_shm_*() functions should be
> > > implemented on all platforms, in all configurations.
>
> It's amazing, but that's not what I meant. If you go back to
> my original note about all of this, I simply pointed out that
> we had made a design decision to get rid of all of these stub
> functions from APR only to have them put back into functions.
Sorry, didn't grok you (unusual, that :-)
> The solution that I like best is to have the feature macro
> which the core
> uses to implement a server_wide allocation function, using
> either palloc
> or malloc or ap_shm_malloc depending on the context and MPM.
I don't believe palloc/malloc map well to shm. But show us
otherwise if you like.
> > But I have one question about ap_shm_ functions... do we have
> > any implicit/explicit assumption that the memory in process A
> > is at the same physical address as process B? This is a HUGE
> > question under Win32, and probably other hybrid kernels.
>
> No, that assumption should never be made, because it simply
> isn't valid in most shared memory implementations. I believe
> Apache makes that assumption (althought I could be wrong).
> I am 99.999% sure that APR makes no such assumption.
Yes, but it's not APR that does anything with the shm, other than
expose it :-) Sounds like this will be doable in Win32 after all.
I guess if that's the case, I'd like to see us change the args or
return type (typedefed to void *) to make this explicitly clear,
perhaps have the shm_open return a base pointer and shm_malloc
and shm_calloc return an offset type to that base.
RE: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by rb...@covalent.net.
> > I'm with Ryan on this. The ap_shm_*() functions should be
> > implemented on all platforms, in all configurations.
It's amazing, but that's not what I meant. If you go back to my original
note about all of this, I simply pointed out that we had made a design
decision to get rid of all of these stub functions from APR only to have
them put back into functions.
The solution that I like best is to have the feature macro which the core
uses to implement a server_wide allocation function, using either palloc
or malloc or ap_shm_malloc depending on the context and MPM.
> I think it is a different thing to build in the feature set
> into APR than to require it under an MPM or other module.
> I like the idea of the MPM 'emulating' shared memory for
> thread-only storage, since the code is written _ONCE_ and if
> it is working under true shmem, it _will_ work under the
> MPM's simple ap_pmalloc/ap_pfree wrappers.
>
> That's all I'm piping in... feel free to go return to your
> regularly scheduled debates :-)
>
> But I have one question about ap_shm_ functions... do we have
> any implicit/explicit assumption that the memory in process A
> is at the same physical address as process B? This is a HUGE
> question under Win32, and probably other hybrid kernels.
No, that assumption should never be made, because it simply isn't valid in
most shared memory implementations. I believe Apache makes that
assumption (althought I could be wrong). I am 99.999% sure that APR makes
no such assumption.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Thursday, June 01, 2000 4:07 PM
>
> I'm with Ryan on this. The ap_shm_*() functions should be
> implemented on all platforms, in all configurations.
>
> APR_HAS_SHARED_MEMORY is available at compile-time to let you
> know that ap_shm_init() is going to return APR_ENOTIMPL. Of
> course, you can also do a runtime test.
I can live with this, throughout apr, although I think we need
to be VERY clear where the feature set boundries lie, and plan
out what points can fail. The obvious statement, if ap_grp_x
returns APR_ENOTIMPL, then ap_grp_y MUST return APR_ENOTIMPL.
Now what about subsets/supersets :-)
But I'm getting past myself, and have been trying to avoid
the two ongoing streams of consiousness. I'm simply trying to
implement shmem on Win32, not that we need it or want it :-)
I think it is a different thing to build in the feature set
into APR than to require it under an MPM or other module.
I like the idea of the MPM 'emulating' shared memory for
thread-only storage, since the code is written _ONCE_ and if
it is working under true shmem, it _will_ work under the
MPM's simple ap_pmalloc/ap_pfree wrappers.
That's all I'm piping in... feel free to go return to your
regularly scheduled debates :-)
But I have one question about ap_shm_ functions... do we have
any implicit/explicit assumption that the memory in process A
is at the same physical address as process B? This is a HUGE
question under Win32, and probably other hybrid kernels.
Of course, this implies you may NEVER have a pointer x in any
shm_alloc'ed structure in the conventional sense. First, if
you point at the int y in the same shm, you will find that the
address of y jumped in process 2. You CAN use the relative
offset of y from x to store the pointer, and that offset will
remain the same.
Worse, if you aren't paying attention, and allocate pointer x
in the shm_alloc'ed structure to point at y, but y is sitting
in ANOTHER shm_init'ed pool, you cannot point, you cannot take
a relative address from x to y. You can only take the relative
address from the offset of the second shm_alloc'ed pool.
I ask because I'm afraid I already know the answer. If we assume
a true absolute address across processes, it will be an 80+ hour
(possibly 200+ hour) investment on someone's part to force
allocations to occur in common open 'slots' between the processes.
I can think of 15 ways to accomplish this under WinNT, not one of
them is simple. 9x is trivial.
That's way outside of my scope of personal interest in the Apache
project into a direction that doesn't professionally excite me.
If I'm plesantly suprized by the answer, the solution is trivial,
and I'll hack out an implementation over the next week.
Bill
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
> Date: Thu, 1 Jun 2000 18:04:22 -0700
> From: Manoj Kasichainula <ma...@io.com>
>
> On Thu, Jun 01, 2000 at 08:41:53PM -0400, Jeff Trawick wrote:
> > . it is a bug in the app if it doesn't use the feature test macro
>
> Not really. If my module requires shared memory, why bother filling up
> my code with macros that test for it? Just fail to compile.
#include "apr.h"
#if !APR_HAS_WIDGET || !APR_HAS_DOODAD || !APR_HAS_THINGAMABOBBER
#error You stupid shit! Read the doc!
#endif
Is this module full of tests?
>
> > The APR_ENOTIMPL flavor of the function enables some possible
> > simplification for app writers that play by the rules. (Consider that
> > you gotta check those return codes anyway; you can't just call
> > ap_xlate_open() and ignore the return code anywhere.)
>
> Yeah, but you have to add an extra check for ENOTIMPL. Error checking
> code is intrusive enough as it is.
rv = ap_create_widget(...);
if (rv) {
fprintf(stderr, "ap_create_widget() failed: %s\n",
ap_strerror(rv, buf, sizeof buf));
}
Granted, that may not be useful for all apps, but it is o.k. for some
and there is no check for APR_ENOTIMPL.
Some apps are just going to need to check for APR_HAS_WIDGET, and it
is helpful whether or not we have the APR_ENOTIMPL flavor. For apps
where some obscure option fails due to !APR_HAS_WIDGET, normal error
handling can catch.
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by Manoj Kasichainula <ma...@io.com>.
On Thu, Jun 01, 2000 at 08:41:53PM -0400, Jeff Trawick wrote:
> . it is a bug in the app if it doesn't use the feature test macro
Not really. If my module requires shared memory, why bother filling up
my code with macros that test for it? Just fail to compile.
> The APR_ENOTIMPL flavor of the function enables some possible
> simplification for app writers that play by the rules. (Consider that
> you gotta check those return codes anyway; you can't just call
> ap_xlate_open() and ignore the return code anywhere.)
Yeah, but you have to add an extra check for ENOTIMPL. Error checking
code is intrusive enough as it is.
Re: Religious discussion #48,523: how to code unimplemented functions
Posted by "Life is hard, and then you die" <ro...@innovation.ch>.
This is safe and makes perfect sense. If it's a no-op, then implement it
as such. This is a completely different issue from the APR_HAS_XYZ vs.
APR_ENOTIMPL discussion, but a valid one.
Cheers,
Ronald
On Fri, Jun 02, 2000 at 07:15:43PM -0700, Manoj Kasichainula wrote:
> Happy, Roy?
>
> On Fri, Jun 02, 2000 at 09:25:11AM -0700, rbb@covalent.net wrote:
> > I will discuss the APR_ENOTIMPL solution, I will advocate the compile time
> > breakage, and I will fight a mixture of the two.
>
> OK, I'm going to propose a slight twist on my earlier proposal. I
> think it's a good change, but it could definitely get more confusing,
> so I won't push it too hard.
>
> If the function can semantically be implemented on a system, even if
> the system doesn't provide a specific function for it, then it would
> be best for APR to provide an implementation of it. Here's what I
> mean:
>
> When writing a thread-safe module, it makes sense to add calls to do
> thread locking of shared structures. It's a minor pain though, to code
> around these locks on a system without threads.
>
> So look at the semantics here. A thread mutex says "don't let any
> other threads touch this code while I'm touching it." The equivalent
> of this on a system without threads is a no-op, so it makes 100% sense
> to say thread locking is a no-op in this case.
>
> This would apply similarly for shared memory on a system without
> per-process memory restrictions (TPF?). Just make it malloc. However,
> if you have a system that does protect memory between processes that
> doesn't have shmem support, then turn off the feature macro and don't
> implement the function.
>
> What do y'all think?
Religious discussion #48,523: how to code unimplemented functions
Posted by Manoj Kasichainula <ma...@io.com>.
Happy, Roy?
On Fri, Jun 02, 2000 at 09:25:11AM -0700, rbb@covalent.net wrote:
> I will discuss the APR_ENOTIMPL solution, I will advocate the compile time
> breakage, and I will fight a mixture of the two.
OK, I'm going to propose a slight twist on my earlier proposal. I
think it's a good change, but it could definitely get more confusing,
so I won't push it too hard.
If the function can semantically be implemented on a system, even if
the system doesn't provide a specific function for it, then it would
be best for APR to provide an implementation of it. Here's what I
mean:
When writing a thread-safe module, it makes sense to add calls to do
thread locking of shared structures. It's a minor pain though, to code
around these locks on a system without threads.
So look at the semantics here. A thread mutex says "don't let any
other threads touch this code while I'm touching it." The equivalent
of this on a system without threads is a no-op, so it makes 100% sense
to say thread locking is a no-op in this case.
This would apply similarly for shared memory on a system without
per-process memory restrictions (TPF?). Just make it malloc. However,
if you have a system that does protect memory between processes that
doesn't have shmem support, then turn off the feature macro and don't
implement the function.
What do y'all think?
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by rb...@covalent.net.
On Fri, 2 Jun 2000, Rodent of Unusual Size wrote:
> rbb@covalent.net wrote:
> >
> > I seriously hate having some functions return APR_ENOTIMPL and others
> > cause a compile break. I will fight this tooth and nail because it
> > changes the rules on developers half-way through the game. :-)
>
> I agree, but not because we're changing the rules 'half-way through
> the game.' We're still in alpha, and there ARE no rules.
Sorry, I wasn't clear. I didn't mean the rules of Apache 2.0. I dislike
the APR_ENOTIMPL for the reasons stated in October. I dislike having a
mix of APR_ENOTIMPL and compile breakage because it changes the rules
within the same version of APR.
I will discuss the APR_ENOTIMPL solution, I will advocate the compile time
breakage, and I will fight a mixture of the two.
I hope that clears up the "Breaking the rules" statement above.
> Consistency is necessary, so either APR_ENOTIMPL or compile breakage,
> but not a mix.
That's what I was trying to say, you do it much better than me
though. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
rbb@covalent.net wrote:
>
> I seriously hate having some functions return APR_ENOTIMPL and others
> cause a compile break. I will fight this tooth and nail because it
> changes the rules on developers half-way through the game. :-)
I agree, but not because we're changing the rules 'half-way through
the game.' We're still in alpha, and there ARE no rules.
Consistency is necessary, so either APR_ENOTIMPL or compile breakage,
but not a mix.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
Re: 1.3.13 moving targets
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Rodent of Unusual Size wrote:
>
> And I'd like to get the mod_setenvif change in for 1.3.13,
> as well. I'm having a problem with the merging, but I should
> have a patch for review to-night or this week-end. Or shall I
> just commit it?
This turned out to be a little more complicated than I thought.
mod_setenvif currently does the envariable processing during
the post-read-request phase.. which is before the URI has been
translated to a filesystem path, and so no per-dir stuff can
be done. I've worked around that by running the env-setter
twice, once during post-read-request and once during header-parse,
and only dealing with the appropriate directives in each call
(i.e., the second call doesn't process any entries the first one
has already done), but the result is a somewhat more involved
patch than I anticipated. I'll post it separately.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
Re: 1.3.13 moving targets
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"William A. Rowe, Jr." wrote:
>
> Here's my shortlist of Win32 issues to fix before we roll:
And I'd like to get the mod_setenvif change in for 1.3.13,
as well. I'm having a problem with the merging, but I should
have a patch for review to-night or this week-end. Or shall I
just commit it?
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
RE: 1.3.13 moving targets
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
Fixed... it was the service dependency, 80% of the time, that
IP or the internal routing hadn't started. 20% of the problems
are firewall products that mess with our listeners.
> -----Original Message-----
> From: Rodent of Unusual Size [mailto:Ken.Coar@Golux.Com]
> Sent: Friday, June 02, 2000 1:59 PM
> To: new-httpd@apache.org
> Subject: Re: 1.3.13 moving targets
>
>
> "William A. Rowe, Jr." wrote:
> >
> > Here's my shortlist of Win32 issues to fix before we roll:
> >
> > 1) Add a simple hold console open patch (wait for close or
> > the ESC key, with a nice message) if the server died a
> > bad death (non-zero exit code) in console mode. Add the
> > ConsoleHandler to deal with Ctrl+C/Ctrl+Break and, at
> > least under NT, shutdown, logoff and window close.
>
> Does this item also address the dreaded 'Error 1067' NT service
> alert?
> --
> #ken P-)}
>
> Ken Coar <http://Golux.Com/coar/>
> Apache Software Foundation <http://www.apache.org/>
> "Apache Server for Dummies" <http://Apache-Server.Com/>
> "Apache Server Unleashed" <http://ApacheUnleashed.Com/>
>
RE: 1.3.13 moving targets
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Rodent of Unusual Size [mailto:Ken.Coar@Golux.Com]
> Sent: Friday, June 02, 2000 1:59 PM
>
> "William A. Rowe, Jr." wrote:
> >
> > Here's my shortlist of Win32 issues to fix before we roll:
> >
> > 1) Add a simple hold console open patch (wait for close or
> > the ESC key, with a nice message) if the server died a
> > bad death (non-zero exit code) in console mode. Add the
> > ConsoleHandler to deal with Ctrl+C/Ctrl+Break and, at
> > least under NT, shutdown, logoff and window close.
>
> Does this item also address the dreaded 'Error 1067' NT service
> alert?
Skim the manual/windows.html file (either 1.3.13-dev or 2.0) for
the very long winded description of the problem :-)
Re: 1.3.13 moving targets
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"William A. Rowe, Jr." wrote:
>
> Here's my shortlist of Win32 issues to fix before we roll:
>
> 1) Add a simple hold console open patch (wait for close or
> the ESC key, with a nice message) if the server died a
> bad death (non-zero exit code) in console mode. Add the
> ConsoleHandler to deal with Ctrl+C/Ctrl+Break and, at
> least under NT, shutdown, logoff and window close.
Does this item also address the dreaded 'Error 1067' NT service
alert?
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
RE: 1.3.13 moving targets
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Scott Sanders [mailto:scott@eionline.com]
> Sent: Friday, June 02, 2000 9:55 PM
>
> I have finished my look into the files windows.html and
> win_compiling.html.
>
> I installed Windows 2000 Server clean, installed Visual
> Studio 6 clean,
> built CVS from source, did a checkout of apache-1.3, followed the the
> instructions to build both debug and release versions from
> the command-line,
> and from Visual Studio, installed the release version, got it running,
> stopped it, installed as a service, ran it, uninstalled the service.
>
> This all happened in 25 minutes. Slick as a whistle.
>
> You guys rock!
Well I'll share that compliment, thankyouverymuch :-)
> Scott Sanders
>
> PS: the only thing I would add to the windows.html file is
> that it runs on
> Win2K, but that is up to you guys if you feel it has been
> tested enough. I
> run Apache 1.3.12 on 3 win2k machines, one of which is using
> virtual hosts,
> all without a hitch.
Actually, REALLY important question - did you ever encounter the
error 1067 bug or any other aspects of the crossed-up dependency
problem?
I ask because I'd like to assure we really licked it.
Bill
RE: 1.3.13 moving targets
Posted by Scott Sanders <sc...@eionline.com>.
I have finished my look into the files windows.html and win_compiling.html.
I installed Windows 2000 Server clean, installed Visual Studio 6 clean,
built CVS from source, did a checkout of apache-1.3, followed the the
instructions to build both debug and release versions from the command-line,
and from Visual Studio, installed the release version, got it running,
stopped it, installed as a service, ran it, uninstalled the service.
This all happened in 25 minutes. Slick as a whistle.
You guys rock!
Scott Sanders
PS: the only thing I would add to the windows.html file is that it runs on
Win2K, but that is up to you guys if you feel it has been tested enough. I
run Apache 1.3.12 on 3 win2k machines, one of which is using virtual hosts,
all without a hitch.
-----Original Message-----
From: Scott Sanders [mailto:scott@eionline.com]
Sent: Friday, June 02, 2000 2:59 PM
To: new-httpd@apache.org
Subject: RE: 1.3.13 moving targets
I would be happy to try and tackle number 3
I will look at it on the weekend.
Thanks
Scott Sanders
-----Original Message-----
From: William A. Rowe, Jr. [mailto:wrowe@lnd.com]
Sent: Friday, June 02, 2000 11:52 AM
To: new-httpd@apache.org; trawickj@bellsouth.net
Subject: 1.3.13 moving targets
Here's my shortlist of Win32 issues to fix before we roll:
<snip/>
3) Assure the windows.html and win_compiling.html reflect
reality, today.
<snip/>
RE: 1.3.13 moving targets
Posted by Scott Sanders <sc...@eionline.com>.
I would be happy to try and tackle number 3
I will look at it on the weekend.
Thanks
Scott Sanders
-----Original Message-----
From: William A. Rowe, Jr. [mailto:wrowe@lnd.com]
Sent: Friday, June 02, 2000 11:52 AM
To: new-httpd@apache.org; trawickj@bellsouth.net
Subject: 1.3.13 moving targets
Here's my shortlist of Win32 issues to fix before we roll:
<snip/>
3) Assure the windows.html and win_compiling.html reflect
reality, today.
<snip/>
Re: 1.3.13 moving targets
Posted by Greg Stein <gs...@lyra.org>.
Please insert all four of these items into the STATUS file under
"Showstoppers", so they can be tracked for a longer period than this email
thread :-)
[ if people miss this email, they can always find this in the STATUS file,
which Ken auto-sends every couple days or so ]
thx,
-g
On Fri, 2 Jun 2000, William A. Rowe, Jr. wrote:
>
> Here's my shortlist of Win32 issues to fix before we roll:
>
> 1) Add a simple hold console open patch (wait for close or
> the ESC key, with a nice message) if the server died a
> bad death (non-zero exit code) in console mode. Add the
> ConsoleHandler to deal with Ctrl+C/Ctrl+Break and, at
> least under NT, shutdown, logoff and window close.
>
> 2) Assure we haven't drifted too far between httpd.conf-dist
> and httpd.conf-dist-win.
>
> 3) Assure the windows.html and win_compiling.html reflect
> reality, today.
>
> 4) Get a CHANGES entry from Mike on the NW commit of
> yesterday (nudge, nudge)
>
> That's three little things, but if someone wants to grab one
> and run with it be my guest! I've got the handle on the
> first issue myself, already.
>
> I'm sure some folk want to review the stat() success on failure
> scenario, to prevent other future holes from popping up there.
>
> Finally, is there any value in mod_proxy creating the ProxyRoot
> directory if it does not exist? If you think there is, what
> should the permission mask be (unix)?
>
>
--
Greg Stein, http://www.lyra.org/
1.3.13 moving targets
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
Here's my shortlist of Win32 issues to fix before we roll:
1) Add a simple hold console open patch (wait for close or
the ESC key, with a nice message) if the server died a
bad death (non-zero exit code) in console mode. Add the
ConsoleHandler to deal with Ctrl+C/Ctrl+Break and, at
least under NT, shutdown, logoff and window close.
2) Assure we haven't drifted too far between httpd.conf-dist
and httpd.conf-dist-win.
3) Assure the windows.html and win_compiling.html reflect
reality, today.
4) Get a CHANGES entry from Mike on the NW commit of
yesterday (nudge, nudge)
That's three little things, but if someone wants to grab one
and run with it be my guest! I've got the handle on the
first issue myself, already.
I'm sure some folk want to review the stat() success on failure
scenario, to prevent other future holes from popping up there.
Finally, is there any value in mod_proxy creating the ProxyRoot
directory if it does not exist? If you think there is, what
should the permission mask be (unix)?
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by rb...@covalent.net.
> > APR does provide feature test macros for all features that can currently
> > be turned on or off. As more features are toggle-able, more test macros
> > will be introduced.
>
> Yep (I didn't mean to imply that APR has such a bug but instead that
> APR will do the right thing in this regard)
Oh, just checking.
> > I seriously hate having some functions return APR_ENOTIMPL and others
> > cause a compile break. I will fight this tooth and nail because it
> > changes the rules on developers half-way through the game. :-)
>
> What developers? Us? Which rule got changed depends on which of your
> posts you look at. You decided that ap_xlate_* should return
> APR_ENOTIMPL if not implemented, and even made sure that it was a
> macro and not a dummy function (not sure why, since we don't generally
> care about the performance of a function which always fails). I
> wasn't too keen on this at first, feeling that we shouldn't provide
> the dummy function, but after putting calls to ap_xlate_* routines and
> seeing that the right thing happened* even when ap_xlate_* wasn't
> implemented, providing the dummy functions started to feel like the
> Right Thing, giving the user of APR a choice at a fairly small cost to
> APR.
This was my mistake at the beginning of implementing the APR iconv
stuff. We should have had a feature macro and not implemented it for
those platforms that don't need/want iconv. I believe my thinking at the
time was that Unix platforms may need to use iconv for translating to
double-byte character sets, so we need to at least have some
implementation. Of course I could be mis-remembering or in a haze when I
first implemented those things. All I really remember about it is that I
have less than a week left at IBM and I was the only one with the design
in my inbox. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
> From: rbb@covalent.net
> Date: Fri, 2 Jun 2000 09:06:06 -0700 (PDT)
>
> > > And I continue to insist that returning ENOTIMPL means that you're
> > > hiding the fact that different function sets are implemented on
> > > different platforms.
> >
> > Sure. But whether or not there is the APR_ENOTIMPL flavor of the
> > function:
> >
> > . it is a bug in APR if APR doesn't provide the appropriate feature
> > test macro
>
> APR does provide feature test macros for all features that can currently
> be turned on or off. As more features are toggle-able, more test macros
> will be introduced.
Yep (I didn't mean to imply that APR has such a bug but instead that
APR will do the right thing in this regard)
>
> I seriously hate having some functions return APR_ENOTIMPL and others
> cause a compile break. I will fight this tooth and nail because it
> changes the rules on developers half-way through the game. :-)
What developers? Us? Which rule got changed depends on which of your
posts you look at. You decided that ap_xlate_* should return
APR_ENOTIMPL if not implemented, and even made sure that it was a
macro and not a dummy function (not sure why, since we don't generally
care about the performance of a function which always fails). I
wasn't too keen on this at first, feeling that we shouldn't provide
the dummy function, but after putting calls to ap_xlate_* routines and
seeing that the right thing happened* even when ap_xlate_* wasn't
implemented, providing the dummy functions started to feel like the
Right Thing, giving the user of APR a choice at a fairly small cost to
APR.
*whether or not the right thing will happen is application-specific
>
> Ryan
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
>
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by rb...@covalent.net.
> > And I continue to insist that returning ENOTIMPL means that you're
> > hiding the fact that different function sets are implemented on
> > different platforms.
>
> Sure. But whether or not there is the APR_ENOTIMPL flavor of the
> function:
>
> . it is a bug in APR if APR doesn't provide the appropriate feature
> test macro
APR does provide feature test macros for all features that can currently
be turned on or off. As more features are toggle-able, more test macros
will be introduced.
I seriously hate having some functions return APR_ENOTIMPL and others
cause a compile break. I will fight this tooth and nail because it
changes the rules on developers half-way through the game. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
> Date: Thu, 1 Jun 2000 16:31:43 -0700
> From: Manoj Kasichainula <ma...@io.com>
>
> On Thu, Jun 01, 2000 at 07:40:33PM -0400, Rodent of Unusual Size wrote:
> > I continue to prefer the original model, with all functions
> > being available in APR on all platforms, even if some of
> > them *do* return APR_ENOTIMPL. I don't like the idea of
> > a portability library that has different function sets on
> > different platforms.
>
> And I continue to insist that returning ENOTIMPL means that you're
> hiding the fact that different function sets are implemented on
> different platforms.
Sure. But whether or not there is the APR_ENOTIMPL flavor of the
function:
. it is a bug in APR if APR doesn't provide the appropriate feature
test macro
. it is a bug in the app if it doesn't use the feature test macro
(but then if there is the APR_ENOTIMPL flavor it can simply respond
appropriately to APR_ENOTIMPL)
>
> OTOH, in cases where a function isn't needed, as opposed to being
> unimplementable, I'd probably agree with you.
The APR_ENOTIMPL flavor of the function enables some possible
simplification for app writers that play by the rules. (Consider that
you gotta check those return codes anyway; you can't just call
ap_xlate_open() and ignore the return code anywhere.)
The APR_ENOTIMPL flavor of the function doesn't do any favors for app
writers that don't play by the rules.
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by Manoj Kasichainula <ma...@io.com>.
On Thu, Jun 01, 2000 at 07:40:33PM -0400, Rodent of Unusual Size wrote:
> I continue to prefer the original model, with all functions
> being available in APR on all platforms, even if some of
> them *do* return APR_ENOTIMPL. I don't like the idea of
> a portability library that has different function sets on
> different platforms.
And I continue to insist that returning ENOTIMPL means that you're
hiding the fact that different function sets are implemented on
different platforms.
OTOH, in cases where a function isn't needed, as opposed to being
unimplementable, I'd probably agree with you.
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by Greg Stein <gs...@lyra.org>.
On Thu, 1 Jun 2000, Rodent of Unusual Size wrote:
> I continue to prefer the original model, with all functions
> being available in APR on all platforms, even if some of
> them *do* return APR_ENOTIMPL. I don't like the idea of
> a portability library that has different function sets on
> different platforms.
Same. (and that is what I had presumed was the current model...)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
I continue to prefer the original model, with all functions
being available in APR on all platforms, even if some of
them *do* return APR_ENOTIMPL. I don't like the idea of
a portability library that has different function sets on
different platforms.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by "Life is hard, and then you die" <ro...@innovation.ch>.
On Thu, Jun 01, 2000 at 03:18:54PM -0700, Greg Stein wrote:
> On Thu, 1 Jun 2000 rbb@covalent.net wrote:
> >
> > How do you feel about having MPMs which don't need shared memory
> > re-implementing ap_shm_* with malloc/free?
>
> Icky.
>
> The problem is when somebody goes to read the code. They will see ap_shm_
> calls in there, and get thrown off on what is really happening.
>
> The MPM is, more than likely, going to need to make changes other than a
> simple malloc/free substitution. I'd rather see the SHM (or not) decision
> grouped up within the MPM, rather than stub some with ap_shm_* plus some
> other bits. Kind of hard to explain here... :-)
The MPM's should be exporting mpm_shm_*, not overridding ap_shm_*.
Cheers,
Ronald
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by Greg Stein <gs...@lyra.org>.
On Thu, 1 Jun 2000 rbb@covalent.net wrote:
>...
> > Heh. Then I'm confused :-)
> >
> > I'd say that APR should stub the things, much like it stubs the XLATE
> > stuff.
> >
> > Well... whatever. :-) Basic point is that the stubs for ap_shm_* in
> > mod_auth_digest are ugly and a different solution ought to be found.
>
> Actually, the XLATE stuff should be changed to match the rest of APR. :-)
>
> How do you feel about having MPMs which don't need shared memory
> re-implementing ap_shm_* with malloc/free?
Icky.
The problem is when somebody goes to read the code. They will see ap_shm_
calls in there, and get thrown off on what is really happening.
The MPM is, more than likely, going to need to make changes other than a
simple malloc/free substitution. I'd rather see the SHM (or not) decision
grouped up within the MPM, rather than stub some with ap_shm_* plus some
other bits. Kind of hard to explain here... :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by rb...@covalent.net.
> > > APR_HAS_SHARED_MEMORY is available at compile-time to let you know that
> > > ap_shm_init() is going to return APR_ENOTIMPL. Of course, you can also do
> > > a runtime test.
> >
> > Ummmm.... no. If APR_HAS_SHARED_MEMORY is not defined, ap_shm_init is not
> > declared and the linker will die. There is no way to return APR_ENOTIMPL
> > from the shared memory routines if the platform doesn't implement shared
> > memory. This was a group decision made about a year ago.
>
> Heh. Then I'm confused :-)
>
> I'd say that APR should stub the things, much like it stubs the XLATE
> stuff.
>
> Well... whatever. :-) Basic point is that the stubs for ap_shm_* in
> mod_auth_digest are ugly and a different solution ought to be found.
Actually, the XLATE stuff should be changed to match the rest of APR. :-)
How do you feel about having MPMs which don't need shared memory
re-implementing ap_shm_* with malloc/free?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by Greg Stein <gs...@lyra.org>.
On Thu, 1 Jun 2000 rbb@covalent.net wrote:
> On Thu, 1 Jun 2000, Greg Stein wrote:
> > I'm with Ryan on this. The ap_shm_*() functions should be implemented on
> > all platforms, in all configurations.
> >
> > APR_HAS_SHARED_MEMORY is available at compile-time to let you know that
> > ap_shm_init() is going to return APR_ENOTIMPL. Of course, you can also do
> > a runtime test.
>
> Ummmm.... no. If APR_HAS_SHARED_MEMORY is not defined, ap_shm_init is not
> declared and the linker will die. There is no way to return APR_ENOTIMPL
> from the shared memory routines if the platform doesn't implement shared
> memory. This was a group decision made about a year ago.
Heh. Then I'm confused :-)
I'd say that APR should stub the things, much like it stubs the XLATE
stuff.
Well... whatever. :-) Basic point is that the stubs for ap_shm_* in
mod_auth_digest are ugly and a different solution ought to be found.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by rb...@covalent.net.
On Thu, 1 Jun 2000, Greg Stein wrote:
> I'm with Ryan on this. The ap_shm_*() functions should be implemented on
> all platforms, in all configurations.
>
> APR_HAS_SHARED_MEMORY is available at compile-time to let you know that
> ap_shm_init() is going to return APR_ENOTIMPL. Of course, you can also do
> a runtime test.
Ummmm.... no. If APR_HAS_SHARED_MEMORY is not defined, ap_shm_init is not
declared and the linker will die. There is no way to return APR_ENOTIMPL
from the shared memory routines if the platform doesn't implement shared
memory. This was a group decision made about a year ago.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by Greg Stein <gs...@lyra.org>.
I'm with Ryan on this. The ap_shm_*() functions should be implemented on
all platforms, in all configurations.
APR_HAS_SHARED_MEMORY is available at compile-time to let you know that
ap_shm_init() is going to return APR_ENOTIMPL. Of course, you can also do
a runtime test.
Cheers,
-g
On Thu, 1 Jun 2000 rbb@covalent.net wrote:
> We talked about this a long time ago, but I'll bring it up again because
> of this commit. When APR was first implemented, all platforms ALWAYS
> implemented all functions. If a function wasn't actually implemented, it
> returned APR_ENOTIMPL. People yelled and screamed and said the linker
> should die because it will be easier for the programmer. Now, we are
> adding back in those dummy functions in a module, yuck!
>
> Just food for thought.
>
> Ryan
>
> > don't include apr_shmem.h when APR_HAS_SHARED_MEMORY is false, but instead set up our own dummies
>
> > +#if APR_HAS_SHARED_MEMORY
> > +#include "apr_shmem.h"
> > +#else
> > +/* just provide dummies - the code does run-time checks anyway */
> > +typedef void ap_shmem_t;
> > +typedef void ap_shm_name_t;
> > +
> > +ap_status_t ap_shm_init(ap_shmem_t **m, ap_size_t reqsize, const char *file, ap_pool_t *cont) {
> > + return APR_ENOTIMPL;
> > +}
> > +ap_status_t ap_shm_destroy(ap_shmem_t *m) {
> > + return APR_ENOTIMPL;
> > +}
> > +void *ap_shm_malloc(ap_shmem_t *c, ap_size_t reqsize) {
> > + return NULL;
> > +}
> > +void *ap_shm_calloc(ap_shmem_t *shared, ap_size_t size) {
> > + return NULL;
> > +}
> > +ap_status_t ap_shm_free(ap_shmem_t *shared, void *free) {
> > + return APR_ENOTIMPL;
> > +}
> > +ap_status_t ap_get_shm_name(ap_shmem_t *c, ap_shm_name_t **name) {
> > + return APR_ENOTIMPL;
> > +}
> > +ap_status_t ap_set_shm_name(ap_shmem_t *c, ap_shm_name_t *name) {
> > + return APR_ENOTIMPL;
> > +}
> > +ap_status_t ap_open_shmem(ap_shmem_t *c) {
> > + return APR_ENOTIMPL;
> > +}
> > +ap_status_t ap_shm_avail(ap_shmem_t *c, ap_size_t *avail) {
> > + return APR_ENOTIMPL;
> > +}
> > +#endif
> >
> >
> > /* struct to hold the configuration info */
> >
> >
> >
> >
>
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by rb...@covalent.net.
We talked about this a long time ago, but I'll bring it up again because
of this commit. When APR was first implemented, all platforms ALWAYS
implemented all functions. If a function wasn't actually implemented, it
returned APR_ENOTIMPL. People yelled and screamed and said the linker
should die because it will be easier for the programmer. Now, we are
adding back in those dummy functions in a module, yuck!
Just food for thought.
Ryan
> don't include apr_shmem.h when APR_HAS_SHARED_MEMORY is false, but instead set up our own dummies
> +#if APR_HAS_SHARED_MEMORY
> +#include "apr_shmem.h"
> +#else
> +/* just provide dummies - the code does run-time checks anyway */
> +typedef void ap_shmem_t;
> +typedef void ap_shm_name_t;
> +
> +ap_status_t ap_shm_init(ap_shmem_t **m, ap_size_t reqsize, const char *file, ap_pool_t *cont) {
> + return APR_ENOTIMPL;
> +}
> +ap_status_t ap_shm_destroy(ap_shmem_t *m) {
> + return APR_ENOTIMPL;
> +}
> +void *ap_shm_malloc(ap_shmem_t *c, ap_size_t reqsize) {
> + return NULL;
> +}
> +void *ap_shm_calloc(ap_shmem_t *shared, ap_size_t size) {
> + return NULL;
> +}
> +ap_status_t ap_shm_free(ap_shmem_t *shared, void *free) {
> + return APR_ENOTIMPL;
> +}
> +ap_status_t ap_get_shm_name(ap_shmem_t *c, ap_shm_name_t **name) {
> + return APR_ENOTIMPL;
> +}
> +ap_status_t ap_set_shm_name(ap_shmem_t *c, ap_shm_name_t *name) {
> + return APR_ENOTIMPL;
> +}
> +ap_status_t ap_open_shmem(ap_shmem_t *c) {
> + return APR_ENOTIMPL;
> +}
> +ap_status_t ap_shm_avail(ap_shmem_t *c, ap_size_t *avail) {
> + return APR_ENOTIMPL;
> +}
> +#endif
>
>
> /* struct to hold the configuration info */
>
>
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/standard mod_auth_digest.c
Posted by rb...@covalent.net.
We talked about this a long time ago, but I'll bring it up again because
of this commit. When APR was first implemented, all platforms ALWAYS
implemented all functions. If a function wasn't actually implemented, it
returned APR_ENOTIMPL. People yelled and screamed and said the linker
should die because it will be easier for the programmer. Now, we are
adding back in those dummy functions in a module, yuck!
Just food for thought.
Ryan
> don't include apr_shmem.h when APR_HAS_SHARED_MEMORY is false, but instead set up our own dummies
> +#if APR_HAS_SHARED_MEMORY
> +#include "apr_shmem.h"
> +#else
> +/* just provide dummies - the code does run-time checks anyway */
> +typedef void ap_shmem_t;
> +typedef void ap_shm_name_t;
> +
> +ap_status_t ap_shm_init(ap_shmem_t **m, ap_size_t reqsize, const char *file, ap_pool_t *cont) {
> + return APR_ENOTIMPL;
> +}
> +ap_status_t ap_shm_destroy(ap_shmem_t *m) {
> + return APR_ENOTIMPL;
> +}
> +void *ap_shm_malloc(ap_shmem_t *c, ap_size_t reqsize) {
> + return NULL;
> +}
> +void *ap_shm_calloc(ap_shmem_t *shared, ap_size_t size) {
> + return NULL;
> +}
> +ap_status_t ap_shm_free(ap_shmem_t *shared, void *free) {
> + return APR_ENOTIMPL;
> +}
> +ap_status_t ap_get_shm_name(ap_shmem_t *c, ap_shm_name_t **name) {
> + return APR_ENOTIMPL;
> +}
> +ap_status_t ap_set_shm_name(ap_shmem_t *c, ap_shm_name_t *name) {
> + return APR_ENOTIMPL;
> +}
> +ap_status_t ap_open_shmem(ap_shmem_t *c) {
> + return APR_ENOTIMPL;
> +}
> +ap_status_t ap_shm_avail(ap_shmem_t *c, ap_size_t *avail) {
> + return APR_ENOTIMPL;
> +}
> +#endif
>
>
> /* struct to hold the configuration info */
>
>
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------