On Sep 29, 2006, at 2:48 PM, Rana Dasgupta wrote:
On 9/26/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
>Just to be clear: I suggest we apply new_queued_cond_var.patch
>attached to HARMONY-1519 - provided that Artem will answer
>comments.
Hi,
I went through both the patches apr_cond.patch and
new_queued_cond_var.patch on H-1519.
There is no perfect solution to implementing conditional waits on
Windows
due to well documented reasons. The original apr implementation was
matching
generations of releases to corresponding waits and the first patch
improves
it, by getting the last waiter to reset the manual event( which seems
logical ). As Artem commented on the JIRA, even this has known
issues...the
loop is inefficient and there can be signal stealing and permanent
waits due
lack of atomicity between apr_thread_mutex_unlock() and
WaitForSingleObject().
Artem's patch new_queued_cond_var.patch looks simple and new, using
synchronized wait queues. Just from reading, it seemed like a good
solution,
there is no way ( at least for me )to understand that it is perfect
without
a lot of testing.
These changes are a maintenance hazard. Are we planning to stay
compatible with APR? I don't know if APR is still an active
community. If
so, we should not commit more changes, and ask on the APR list first.
Thanks for doing this.
My $0.02 - right now, this is a fix that helps make DRLVM more useful
as we go forward, by fixing a problem in APR. If we continue with
APR, we either get this fix in there or maintain ourselves, *or* we
throw APR overboard and do something else.
Either way, I don't see too much harm from a software process POV in
applying. Seems like we need it now.
Thoughts?
geir
Thanks,
Rana
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
