Re: cvs commit: apache-2.0/src/lib/apr/time/unix time.c

[Manoj Kasichainula <ma...@raleigh.ibm.com>]

On Wed, Oct 06, 1999 at 06:48:52AM -0000, rbb@hyperreal.org wrote:
>   +#ifndef _POSIX_THREAD_SAFE_FUNCTIONS
>   +#define SAFETY_LOCK(func_name, cnt, name_str) \
>   +    { \
>   +    struct lock_t *funclock = lock_##func_name; \
>   +    if (funclock == NULL) \
>   +        if (ap_create_lock(cnt, APR_MUTEX, APR_LOCKALL, name_str, &funclock) != APR_SUCCESS) \
>   +            return APR_NOTTHREADSAFE; \
>   +    if (ap_lock(funclock) != APR_SUCCESS) \
>   +        return APR_NOTTHREADSAFE; \
>   +    }

According to Single Unix, any of asctime, ctime, getdate,
gettimeofday, and gmtime can overwrite each other's values. So a
per-function lock isn't enough in this case.

Also, can we assume that if there are nonstandard _r functions (i.e.
_POSIX_THREAD_SAFE_FUNCTIONS is not defined) that they will behave the
same as pthreads/SUS dictate? If not, then we should check for
_POSIX_THREAD_SAFE_FUNCTIONS instead of letting autoconf check for
each _r function individually.

-- 
Manoj Kasichainula - manojk@raleigh.ibm.com
IBM, Apache Development

Re: cvs commit: apache-2.0/src/lib/apr/time/unix time.c

[Ryan Bloom <rb...@raleigh.ibm.com>]

> But, there is one other problem I just noticed, which is that the lock
> is created in the memory context of the first ap_time_t that uses
> SAFETY_LOCK. If that context is destroyed, the lock goes away. The
> lock has to be in a persistant location (NULL context?).

This cannot be helped.  We could use the ap_palloc(NULL, trick but that
will be going away as soon as we all agree on how memory allocation should
be done in APR.  The correct solution, would be to allocate these during
the ap_initialize function that is required in all APR functions.  The
only problem, is that I want to be able to specify that certain APR
modules aren't to be compiled in.  For example, if Apache decides to do
it's own signals work (which I think we have), then when Apache compiles
APR the signaling module should not be included.  I haven't put this
ability into the configure script yet, but I will be doing it soon.  When
I do, that will complicate matters if I have lock creation in
ap_initialize.  The answer to the problem is easy, but the fix that goes
along with that answer is harder.  I'll hopefully get to it soon, but it
has to come after the parameter re-order, the Thread-safe fixes, and the
process work that is currently being done.  I will not make any promises
on when that will be.  In the mean-time, this will work with a minimal
performance hit.

> 
> And why are we using a cross-process lock?

Because I am an idiot and wasn't paying attention.  Fixed sometime today.
:)

> Ralf brought this up as a concern. It appears that there are two
> different defines that indicate the existence of the _r functions.  If
> the _r functions exist on a system with the old define
> (_POSIX_REENTRANT_FUNCTIONS) but not the new one, then they may be
> from an old spec with different definitions. I don't know (and web
> searches have come up with nothing), which is why I'm asking.

I still see this as a broken platform.  However, the framework as it
currently stands, will handle this case with few modifications.  I do not
want to deal with this case right now, because ot makes a lot of the
macros VERY ugly.  If we find out we need this change, we can make it
then.

Ryan

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	

Re: cvs commit: apache-2.0/src/lib/apr/time/unix time.c

[Manoj Kasichainula <ma...@io.com>]

On Wed, Oct 06, 1999 at 05:46:32PM -0400, Ryan Bloom wrote:
> That's fine.  The idea is still valid, and is still the correct one.

You mean the idea of the macros used to provide the locking instead of
doing it directly? Sure.

But, there is one other problem I just noticed, which is that the lock
is created in the memory context of the first ap_time_t that uses
SAFETY_LOCK. If that context is destroyed, the lock goes away. The
lock has to be in a persistant location (NULL context?).

And why are we using a cross-process lock?

> > Also, can we assume that if there are nonstandard _r functions (i.e.
> > _POSIX_THREAD_SAFE_FUNCTIONS is not defined) that they will behave the
> > same as pthreads/SUS dictate? If not, then we should check for
> > _POSIX_THREAD_SAFE_FUNCTIONS instead of letting autoconf check for
> > each _r function individually.
> 
> I don't see this as an issue.  If a system has a function that is defined
> by a standard, and the function doesn't work according to the standard,
> the platform is broken.  Do you know of any such system?  Or, is this
> hand-waving over the issue?

Ralf brought this up as a concern. It appears that there are two
different defines that indicate the existence of the _r functions.  If
the _r functions exist on a system with the old define
(_POSIX_REENTRANT_FUNCTIONS) but not the new one, then they may be
from an old spec with different definitions. I don't know (and web
searches have come up with nothing), which is why I'm asking.

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"Tandems are good if you need hardware which sucks reliably, 24x365."
  -- Malcolm Ray.

Re: cvs commit: apache-2.0/src/lib/apr/time/unix time.c

[Ryan Bloom <rb...@raleigh.ibm.com>]

> According to Single Unix, any of asctime, ctime, getdate,
> gettimeofday, and gmtime can overwrite each other's values. So a
> per-function lock isn't enough in this case.
> 

That's fine.  The idea is still valid, and is still the correct one.  In
this case, we can only protect the functions that APR functions may call,
but there is no way around this.  Of course, this shouldn't be a real
problem anyway, because as Ben pointed out, a threaded system which
doesn't have a real threaded library, is a broken system.  Anyway, the
only change, is instead of calling it with the actual function name,
change everything to use "timefuncs".

> Also, can we assume that if there are nonstandard _r functions (i.e.
> _POSIX_THREAD_SAFE_FUNCTIONS is not defined) that they will behave the
> same as pthreads/SUS dictate? If not, then we should check for
> _POSIX_THREAD_SAFE_FUNCTIONS instead of letting autoconf check for
> each _r function individually.

I don't see this as an issue.  If a system has a function that is defined
by a standard, and the function doesn't work according to the standard,
the platform is broken.  Do you know of any such system?  Or, is this
hand-waving over the issue?

Ryan


_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.