httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <ma...@io.com>
Subject Religious discussion #48,523: how to code unimplemented functions
Date Sat, 03 Jun 2000 02:15:43 GMT
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?


Mime
View raw message