httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Life is hard, and then you die" <ron...@innovation.ch>
Subject Re: Religious discussion #48,523: how to code unimplemented functions
Date Sat, 03 Jun 2000 11:42:28 GMT

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?


Mime
View raw message