Re: Religious discussion #48,523: how to code unimplemented functions

[Mike Gardiner <mg...@novell.com>]

I guess the same would go for OSs that must explicitly yield the processor
in extremely tight loops as is the case with NetWare.  All OSs that are fully
preemptable would define apr_yield as a no-op but on NetWare we would
implement it.  I wouldn't suggest scattering apr_yield code in every single
loop but rather in the very few places where it is actually needed.

-Mike-

>>> manoj@io.com 06/02/00 08:15PM >>>
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?