[Freeciv-Dev] Re: (PR#3513) GUI is unresponsive while handling network events

["Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>]

On Mon, Feb 24, 2003 at 02:34:30AM -0800, Jason Short wrote:
> Raimar Falke wrote:
> > On Sun, Feb 23, 2003 at 11:52:24PM -0800, Jason Short wrote:
> > 
> >>While the client is in the network loop, no user-interface events are
> >>handled.  This means operations like closing popup windows and redrawing
> >>areas that have been invalidated (e.g., by being covered by those popup
> >>windows) don't get done until the end of the network loop.
> > 
> > 
> > The only way I know to avoid this is to use multi-threading. However
> > this will only solve this problem partially. The network thread will
> > set the data to an inconsistent state in a regular way. The GUI thread
> > however won't be amused about inconsistent state. This is a normal
> > problem of multi-threading programming. It is solved by locks. But
> > even when we would use threads and locks I don't think the result will
> > be complete since most of the network code will be run with the lock
> > held. So little gain for a lot of work.
> 
> It's not true that the only solution is multi-threading, but it seems 
> likely that there is no good full solution.
> 
> If the network code only handled one (or a small number of) packet at a 
> time, then when it returned the GUI would handle events before 
> re-entering the network code.  The drawback is it would make the drawing 
> code hideously slow.
> 
> GTK allows you to call a function (gtk_event_iterate or some such) that 
> will handle a single event.  This could be called periodicly through the 
> network loop.  But then we are likely to get more network events and 
> have the network code re-enter - and it is also likely to make the 
> drawing code somewhat slow.

> There are really only a few events that we need to worry about, though. 
>   It may be possible to poll for these events without losing too much 
> efficiency or needing too much code.  One example is the flush_dirty 
> patch, which will handle mapcanvas expose events every time 
> flush_dirty() is called.  Other GUIs aren't likely to have as slick an 
> interface as gtk+-2.0, so this is probably less helpful elsewhere.

So which events of
<http://developer.gnome.org/doc/API/gdk/gdk-events.html#GDKEVENTTYPE>
do you want to handle immediately and which later and why?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "- Amiga Y2K fixes (a bit late, wouldn't you say?)"
    -- Linus Torvalds about linux 2.4.0 at 4 Jan 2001