java-gnome-hackers

[java-gnome-hackers] threads

[Mark H. <mh...@ca...>]

Hi,
  I think you've already found that gtk, like swing, requires that
almost all graphics operations must be performed in a single thread. 

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. 

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.

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).

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

[java-gnome-hackers] threads

[Mark H. <mh...@ca...>]

Hi,
  I've been looking again at the gtk code. I'm not sure if this is new
for gtk 2.2 - I'm sure it wasn't there when I looked last year.

Apparently, Gtk methods can be called from multiple threads, if all  are
enclosed within  gdk_threads_enter()/ gdk_threads_leave() statements
(with a gtk_flush() before the leave()).g_thread_init() and
gdk_threads_init() must also be called from each thread.

Unfortunately I don't have enough time at the moment to look at this in
more detail. I'm not sure whether the enter/leave calls have to be made
if the code is running in the main thread - If they don't, then we could
make modifications easily to allow multiple threads. If they do, then
this may simply mean that the user has to make calls to enter/leave
before modifying the gui. Most callbacks are done in the graphics
thread.
I am also confused by the examples having:
gdk_threads_enter ();
  gtk_main ();
gdk_threads_leave ();
wouldn't this block any other threads acquiring the lock?

Relevant web pages are:
http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html#id2848858
http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

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

Re: [java-gnome-hackers] threads

[Mark H. <mh...@ca...>]

On Mon, 2003-02-24 at 18:44, Tom Ball wrote:
>  Unless you want to develop it, Mark, I'll come up with a
> proposal for some sort of invokeLater.
Go for it. 


Timer:
>  A code review
> by anyone who has the time would be appreciated, however.
I'll have time in about 3 weeks :)
Will you also create a simple example application for this please. 

> Are there really different types of timers?
I guess there aren't many and if they are then they would be better
served by writing a completely custom timer, or using the invokeLater
method. I was just thinking about what we had been told about the Java
Thread class when I wrote the suggestion.
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca...