Re: Patch [ecj]: Central Parking

[Mohan Embar <gnustuff at thisiscool dot com>]

Hi Andrew,

> > This does away with _Jv_ThreadPark and _Jv_ThreadUnpark and keeps
> > park() and unpark() in natUnsafe.cc, thereby allowing a shared
> > implementation using the cross-platform synchronization functions
> > and objects in posix-threads.h and win32-threads.h.  Since the
> > park() implementation uses _Jv_CondNotify, we also get thread
> > interrupt support for free and can do away with the
> > _Jv_ThreadUnpark call in Thread.interrupt().
>
>Surely it's possible to avoid this: the POSIX version doesn't need to
>call _Jv_CondWait and _Jv_CondNotify, and I don't see why the Win
>version should either.  But I guess I don't really mind what the Win
>version does, as long as it passes the tests.

My first inclination was to avoid going down this route too, but:

- Doesn't using _Jv_CondWait make for nicer, cleaner code, both for
  the POSIX version and in terms of reuse?
- I'm not seeing that we need to be overly concerned about
  speed here, since all we're doing is making our bed so
  we can take a nap.
- Isn't it nice to cerntralize interrupt handling in one spot? I thought
  it was cool that I was able to eliminate the call to unpark() in
  Thread.interrupt() and simply augment the comment at the end of
  the call to _Jv_CondWait in park() that this could also occur
  for an interrupt in addition to a timeout.

So my feeling was that these benefits outweighed whatever added overhead
_Jv_CondWait entailed, even for the POSIX version.

>I used the TCK at
>http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/.

If I can get this to pass these tests for the Linux native build, would
you be open to proceeding down this route or not?

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/