At 08:28 AM 8/7/2003, Bill Stoddard wrote:
>[EMAIL PROTECTED] wrote:
>
>>wrowe 2003/08/06 16:54:31
>> Modified:locks/unix proc_mutex.c
>> Log:
>>Introduce the proc_mutex_no_tryacquire stub, returning APR_ENOTIMPL,
>>for all unimplemented trylock vectors. Prevents us from simply
[EMAIL PROTECTED] wrote:
wrowe 2003/08/06 16:54:31
Modified:locks/unix proc_mutex.c
Log:
Introduce the proc_mutex_no_tryacquire stub, returning APR_ENOTIMPL,
for all unimplemented trylock vectors. Prevents us from simply
segfaulting when a given proc_mutex style does not
On Thu, 21 Nov 2002, jean-frederic clere wrote:
> Hi Ryan,
>
> apr_proc_mutex_destroy is still in locks/unix/global_mutex.c.
>
> Do I miss something?
Just a type on my part. I have fixed it. Thanks.
Ryan
>
> Cheers
>
> Jean-frederic
>
>
> [EMAIL PROTECTED] wrote:
> > rbb 2002/11/20
Hi Ryan,
apr_proc_mutex_destroy is still in locks/unix/global_mutex.c.
Do I miss something?
Cheers
Jean-frederic
[EMAIL PROTECTED] wrote:
rbb 2002/11/20 13:11:43
Modified:include apr_proc_mutex.h
include/arch/unix proc_mutex.h
locks/unix proc_mutex.c
L
[EMAIL PROTECTED] wrote:
>
> trawick 02/04/01 13:03:04
>
> Modified:.CHANGES
>locks/unix proc_mutex.c
> Log:
> Get flock-based mutexes to work in apps like Apache. Use the
> same permissions on flock- and fcntl-based mutexes as Apache
> 1.3.
dang, you'r
On 25 Oct 2001, Jeff Trawick wrote:
> Frankly, shirley, whatever, I think apr_file_mktemp() needs a
> parameter to specify the disposition of the file: remove immediately,
> remove at close, don't remove at all.
As far as I can tell, the option to remove immediately is not portable.
It works on U
[EMAIL PROTECTED] writes:
> trawick 01/10/25 07:52:43
>
> Modified:locks/unix proc_mutex.c
> Log:
> Change proc_mutex_fcntl_create() to remove the lock file. There was
> no logic to unlink() the lock file when the user specified the name,
> though when the APR temporary file fa
Aaron Bannert <[EMAIL PROTECTED]> writes:
> locks/unix/crossproc.c:392 is still using errno, should this be changed
> as well to only rely on apr_file_mktemp's return value?
>
> if (rv != APR_SUCCESS) {
> apr_status_t stat = errno;
>
> fcntl_cleanup(new);
> return sta
On Tue, Oct 23, 2001 at 05:46:56PM -, [EMAIL PROTECTED] wrote:
> trawick 01/10/23 10:46:56
>
> Modified:locks/unix proc_mutex.c
> Log:
> return the error that caused the operation to fail, not the current
> errno, since that could have been set due to some cleanup which
> did
