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

[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: Religious discussion #48,523: how to code unimplemented functions

["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?