You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Brian Havard <br...@kheldar.apana.org.au> on 2001/10/21 08:37:05 UTC

Re: cvs commit: apr/locks/win32 proc_mutex.c

On 19 Oct 2001 23:25:28 -0000, aaron@apache.org wrote:

>aaron       01/10/19 16:25:28
>
>  Modified:    include  apr_portable.h
>               locks/beos proc_mutex.c
>               locks/netware proc_mutex.c
>               locks/os2 proc_mutex.c
>               locks/unix proc_mutex.c
>               locks/win32 proc_mutex.c
>  Log:
>  Implement portable accessors for proc mutex. These are equivalent to
>  apr_os_lock_get/set, but they work for apr_proc_mutex_t types instead.
>  
>  I did my best to implement these on non-Unix platforms from how I saw
>  them implemented for apr_os_lock_get/set, but on those platforms they
>  are untested.

Well, this actually breaks things on OS/2 (& probably Win32), not because
there's anything wrong with it but because proc mutexes aren't yet
implemented on either platform so there's no os handle in the
apr_proc_mutex_t to get/set.

I guess I should actually implement them, so are they supposed to be like
APR_LOCKALL or APR_CROSS_PROCESS locks?

-- 
 ______________________________________________________________________________
 |  Brian Havard                 |  "He is not the messiah!                   |
 |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |
 ------------------------------------------------------------------------------


Re: cvs commit: apr/locks/win32 proc_mutex.c

Posted by Aaron Bannert <aa...@clove.org>.
> >  Implement portable accessors for proc mutex. These are equivalent to
> >  apr_os_lock_get/set, but they work for apr_proc_mutex_t types instead.
> >  
> >  I did my best to implement these on non-Unix platforms from how I saw
> >  them implemented for apr_os_lock_get/set, but on those platforms they
> >  are untested.
> 
> Well, this actually breaks things on OS/2 (& probably Win32), not because
> there's anything wrong with it but because proc mutexes aren't yet
> implemented on either platform so there's no os handle in the
> apr_proc_mutex_t to get/set.

Hmm.. Should I #ifdef them out for now?

> I guess I should actually implement them, so are they supposed to be like
> APR_LOCKALL or APR_CROSS_PROCESS locks?

APR_CROSS_PROCESS == apr_proc_mutex_t

We don't have an analog for APR_LOCKALL, and it is still undecided if
we need/want one.

-aaron