After reading an excellent survey ( http://www.cs.wustl.edu/~schmidt/win32-cv-1.html)on implementing posix-style condition variables on windowsxp, its not clear that being dependent on any external posix-to-win32 wrapper is acceptable for Harmony. If this paper is correct, it looks rather tricky to correctly implement condition variables on windows. My take on the whole subject is that Harmony needs to fix and/or morph some "condition variable on win32" thingy. Its OK if the "thingy" happens to be APR. But I would not let APR slow Harmony down. To do condition variables per the paper, the APR code base may change a bunch. Its unclear if the APR crowd will want to incorporate such mods. I lean towards dumping APR.
On 11/29/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
On 11/23/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > > > >Gregory, the locks/win32/thread_cond.c was fixed in HARMONY-1519 on 4 > >Oct. The current patch is definitely more correct than the official > >version (apparently based on the previous patch). Don't know who > >submitted old patched to APR - Artem Aliev? At least he might have > >more complete clue... 1519 was a good fix for conditional variable emulation on Windows and I think was worth submitting back to the apr project. But once we have started making this type of changes, it is harder to upgrade to newer versions directly. Testing 1.2.7 is a good idea, they would have more bug fixes. If good, we could consider moving to 1.2.7 and reapplying our few patches. On Linux, APR seems to just delegate to the POSIX api's and works well, but I think we will discover more fixes on Windows. So we will have to conscientiously keep submitting back ( and hope that they make it ) or move away from apr. As such, I don't think that apr is adding a lot of value.
-- Weldon Washburn Intel Enterprise Solutions Software Division
