apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: cvs commit: apr STATUS
Date Mon, 04 Feb 2002 19:17:38 GMT
Can someone please comment on the state of the OS/2 and Netware lock
implementation? Is it unnecessary or even senseless to implement
a cross-process lock on Netware (where I've been told there are
only threads)?

-aaron


On Mon, Feb 04, 2002 at 07:15:20PM -0000, aaron@apache.org wrote:
> aaron       02/02/04 11:15:20
> 
>   Modified:    .        STATUS
>   Log:
>   The major parts of the new lock API are complete, AFAICT. Move the less
>   critical (or perhaps not implementable) pieces down to non-showstopper
>   status.
>   
>   Left a note that we must not make a release of APR with both lock
>   APIs, or we may have to support both lock APIs forever, which would
>   be unfortunate.
>   
>   Also, it appears that Beos' apr_thread_cond now works, thanks to David.
>   
>   Revision  Changes    Path
>   1.97      +7 -6      apr/STATUS
>   
>   Index: STATUS
>   ===================================================================
>   RCS file: /home/cvs/apr/STATUS,v
>   retrieving revision 1.96
>   retrieving revision 1.97
>   diff -u -r1.96 -r1.97
>   --- STATUS	29 Jan 2002 16:10:14 -0000	1.96
>   +++ STATUS	4 Feb 2002 19:15:20 -0000	1.97
>   @@ -1,5 +1,5 @@
>    APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS:			-*-text-*-
>   -Last modified at [$Date: 2002/01/29 16:10:14 $]
>   +Last modified at [$Date: 2002/02/04 19:15:20 $]
>    
>    Release:
>    
>   @@ -32,12 +32,15 @@
>          since apr_proc_create didn't allocate the apr_proc_t storage.
>          (Aren't transparent types swell?)  Suggestions?
>    
>   +    * The new lock API is a full replacement for the old API. Before
>   +      we do a major APR release, we must deprecate the old locks API,
>   +      lest we support 2 lock APIs in perpetuity.
>   +
>   +RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
>   +
>        * The new lock API is a full replacement for the old API, but is
>          not yet complete on all platforms. Components that are incomplete
>          or missing include:
>   -      Beos: apr_thread_cond_*()
>   -            Initial code committed. Aaron has some concerns, David agrees
>   -            and will find time to address the issues.
>          Netware: apr_proc_mutex_*() (Is proc_mutex unnecessary on Netware?)
>          OS/2: apr_thread_cond_*(), apr_proc_mutex_*()
>    
>   @@ -47,8 +50,6 @@
>          Unix: apr_thread_rwlock_*() for platforms w/o rwlocks in pthread
>          Win32: apr_thread_rwlock_try*lock(), apr_thread_cond_timedwait(),
>                 apr_proc_mutex_*() (Is proc_mutex unnecessary on Win32?)
>   -
>   -RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
>    
>        * Need to contemplate apr_strftime... platforms vary.  OtherBill
>          suggested this solution (but has no time to implement):
>   
>   
>   

Mime
View raw message