Re: [java-gnome-hackers] threads

[Tom B. <Tom...@Su...>]

On Fri, 2003-02-21 at 04:52, Mark Howard wrote:
>   I think you've already found that gtk, like swing, requires that
> almost all graphics operations must be performed in a single thread. 

Thanks for the information; this confirms my guess.  Over the years I've
found that there are very few toolkits that truly support
multi-threading, and those that do require that the app writer jump
through lots of hoops.  If I could change only one thing in Java's core
libraries, I would make the AWT's threading model single-threaded. 
"Keep it simple" as an app model saves everyone a lot of pain later.

> Your timer looks interesting, but I think this would only be useful for
> a limited number of cases. Perhaps it would be more useful to create
> methods similar to SwingUtilities.invokeAndWait(Runnable) and
> SwingUtilities.invokeLater(Runnable), which execute the run method of
> the given class in the graphics thread. These methods are used for
> everything which updates the display from additional threads. 

We have a general problem in that there is no way to create new event
sources in Java-GNOME, which I think is a big hole.  Just implementing
the related GLib functions isn't the answer, however, as that conflicts
with the new event API that Jeffrey designed.  An invokeLater
(invokeAndWait can be easily abused by developers) method would be both
useful and allow us more time to design a proper event source API
later.  Unless you want to develop it, Mark, I'll come up with a
proposal for some sort of invokeLater.

> I was going to suggest at this point that Timer could be based on those,
> but now realise that it would probably have severe performance issues.
> So it's probably best if we have both a timer and invokeLater (or
> similar) methods.

I agree.  If there had been an invokeLater-type interface, I would have
used it, but timers in general really do deserve special treatment
(which is probably why GLib's main loop functions include timer
support).  The Timer code turned out to be quite small, and it actually
worked the first time (gasp!).  By following advice in the JNI manual
and Effective Java, I think the code is close to right.  A code review
by anyone who has the time would be appreciated, however.

> For your API Proposal, I would suggest that you make it more like the
> Thread class, in that the user can either override it (e.g. if they want
> to change it's functionality), or they can supply a Runnable object to
> its constructor (when they want to use the default behaviour).

I think the right answer is a combination of these:  make the class
final (there really isn't any functionality that makes sense to change),
but take a Runnable in its constructor.  I have strong opinions
regarding the correct use of inheritance versus composition, and believe
that inheritance should be reserved for "is a" relationships between
object types, while "have a" relationships should use composition.  

Are there really different types of timers?  Maybe one-shots and
recurrent ones, but one-shots are handled by your invokeAndWait
suggestion.  My guess is that the only difference between recurring
timers are their interval and the code they execute, and these can be
handled by specifying them in a constructor.  My guess is that
application classes normally "have a" timer rather than being one, so
unless there are strong objections, I'll modify Timer to require a
Runnable and interval in its constructor.

Thanks for your feedback,
Tom