Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4329CE76.2020901@rowe-clan.net>
Date: Thu, 15 Sep 2005 14:41:42 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720)
MIME-Version: 1.0
To: ronen@tversity.com
CC: dev@apr.apache.org
Subject: Re: Possible bug in proc_mutex.c on Win32
References: <43226B86.3000105@tversity.com> <4329CA55.2080002@tversity.com>
In-Reply-To: <4329CA55.2080002@tversity.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Ronen Mizrahi wrote:
> OK, I realize I may be doing something wrong, or otherwise someone would 
> have responded to the message below. Could anyone please enlighten me? 
> Have I broken some rules? I assure you if I did it was non intentional. 
> I have the highest appreciation for the ASF and for APR in particular. 
> Can someone please respond?

Oh no - nothing wrong.  I've been pondering your proposal for a bit.

In general APR has attempted NOT to toggle system errors into 'posix'
errors, if you look at apr_errno.h you will see that we've expanded the
APR_STATUS_IS_EFOO() macro to test 'posix' EFOO, and all roughly
equivilant os-specific errors.

The reason's simple, if the end user ignores EFOO, then it's foolish of
us to waste cycles testing for OS_FOO and replacing with the value EFOO.

But in the case of your patch below, can we reliably state that the
APR_STATUS_IS_EBUSY() macro should (on win32/os2) include WAIT_TIMEOUT?
I'm hesitant, and was trying to figure all the scenarios, which is why
I had yet to respond.  What is apr_get_os_error()'s result, SUCCESS or
no-change?  Or have you determined a win32 'error' result in this case
from apr_get_os_error().  If it's unset (not-an-error) then yes, we need
to adopt the patch; if it's set we should look at that error code and
expand APR_STATUS_IS_EBUSY().

Bill


>> Hi,
>>
>> The function apr_proc_mutex_trylock(apr_proc_mutex_t *mutex) is 
>> supposed to return APR_EBUSY if the mutex is already locked, however 
>> it never does that. The following is taken from the SVN head:
>>
>> *APR_DECLARE*(apr_status_t) apr_proc_mutex_trylock(apr_proc_mutex_t 
>> *mutex)
>> {
>>    DWORD rv;
>>
>>    rv = WaitForSingleObject(mutex->handle, 0);
>>
>>    *if* (rv == WAIT_OBJECT_0 || rv == WAIT_ABANDONED) {
>>        *return* APR_SUCCESS;
>>    }
>>    *return* apr_get_os_error();
>> }
>>
>>
>> I suggest modifying it to (based on apr_thread_mutex_trylock()):
>>
>> APR_DECLARE(apr_status_t) apr_proc_mutex_trylock(apr_proc_mutex_t *mutex)
>> {
>>    DWORD rv;
>>
>>    rv = WaitForSingleObject(mutex->handle, 0);
>>
>>    if (rv == WAIT_OBJECT_0 || rv == WAIT_ABANDONED) {
>>        return APR_SUCCESS;
>>    }
>>   return (rv == WAIT_TIMEOUT) ? APR_EBUSY : apr_get_os_error();
>> }
>>
>> Please let me know if this is ok,
>>
>> Ronen
>>
> 
> 
>