Re: Dec 7 commit & Thread safe fields usage (fwd)

Date view Thread view Subject view Author view

From: peter@transvirtual.com
Date: Tue Dec 08 1998 - 10:38:15 EST


Some quick comments on the AWT parts..

>> the volatiles..

As far as Window.nativeData is concerned, I don't think we really need it (even
if volatile would come with auto sync). That could be done much cheaper with a
sync on the Toolkit.class (since the native usage is the interesting one, and
all native calls are Toolkit.class synced). If nobody encountered a problem
with this so far, I would say we leave it for the moment.

>> the clr.c, toolkit.h changes (register -> register int, unsigned -> unsigned
int..)

That's Ok with me. The 'inline' isn't defined on my system, but that might have
been a misconfig.

>> java.awt.Default
>> already have RgbRequests reintroduced by java.awt.RequestRgb.

I still don't see why RgbRequests is required (with the non-native Color ctor +
deferred native Color init, I think it should work with Defaults.RgbRequests),
and I definitely would like to keep the whole config stuff in one place.
However, I was constantly told it doesn't work otherwise (but never was able to
reproduce that on my PseudoColor X servers)

>> java.awt.EventDispatchThread
>> now use WMEvent.getEvent() in place of new WMEvent(), is the comment:
>> "no need to loop, nobody else knows 'e'" again true ?

I think so. The event is just reused *after* it got dispatched/recycled, and
this is the only sync point.

>> java.awt.EventDispatchThread
>> run(Window), show(Window): both use Thread.currentThread() !=
>> Toolkit.eventThread(), should not use Toolkit.isWrongThread() ?
>> java.awt.EventQueue
>> postEvent(), repain(): use Toolkit.isBlocking && (Thread.currentThread()
>> != Toolkit.eventThread), should not use Toolkit.isWrongThread() ?

No, there is no thing like isWrongThread(), anymore. It doesn't provide enough
info, since it combined "isBlocking" and "isDispatchExclusive" in one state,
and that is inappropriate for a lot of windowing systems (e.g. X, which does
blocking getNextEvent(), but does *not* require windows to be
created/destroyed in the dispatcher thread).

>> java.awt.Window
>> removeNotify(), line 227, while (nativeData == null) should be
>> while (nativeData != null)

Yep - that's a bug.

-- Peter


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:08 EDT