apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronen Mizrahi <ro...@tversity.com>
Subject Re: Possible bug in proc_mutex.c on Win32
Date Thu, 15 Sep 2005 21:00:18 GMT
Thank you for your response. The os error is not set in this case. 
According to the documentation on MSDN only when the return value of 
WaitForSingleObject() is WAIT_FAILED will an error be set. I supposed 
this is why the patch I suggest is already the current implementation 
for thread mutexes.
(sorry for emailing it previously to your email address and not to the 
forum)


William A. Rowe, Jr. wrote:

> 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
>>>
>>
>>
>>
>
>


Mime
View raw message