Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2003:
[Freeciv-Dev] Re: (PR#3391) SDL client polls the network
Home

[Freeciv-Dev] Re: (PR#3391) SDL client polls the network

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Rafa? Bursig <bursig@xxxxxxxxx>
Cc: "freeciv-dev@xxxxxxxxxxx" <freeciv-dev@xxxxxxxxxxx>, Jason Dorje Short <vze49r5w@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: (PR#3391) SDL client polls the network
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Wed, 12 Feb 2003 12:11:53 +0100

On Wed, Feb 12, 2003 at 11:22:24AM +0100, Rafa? Bursig wrote:
> 
> >> Currently the SDL client monitors the network connection by polling
> >> every 100 milliseconds for data.  This leads to a lot of lag in
> >updates.
> >>
> >> The correct thing to do is to get an interrupt or callback that is
> >> activated when network data is available.  This is what the other
> >> clients do (although it is possible that the underlying libraries
> >just
> >> do polling, we would hope not).  However, in my brief research I
> >don't
> >> see how to do this with SDL.  Is it possible that this functionality
> >is
> >> not portable?  How could anyone ever program on a system that didn't
> >> provide this?
> >
> >Rafal asked me yesterday the question. I searched a bit and found
> >nothing. The canonical solution looks like this:
> > Thread 1:
> >    1) select on network input
> >    2) push an event in the SDL event queue
> >    3) goto 1)
> > Thread 2:
> >    1) wait for SDL event queue
> >    2) act according to the event (mouse, network)
> >    3) goto 1)
> >
> >The other is polling (see our current code).
> >
> >I completely agree that this is a big design error in SDL.
> >
> >Lets take a look 
> >(http://www.libsdl.org/cgi/cvsweb.cgi/SDL12/src/events/SDL_events.c?rev=1.9&content-type=text/x-cvsweb-markup):
> >
> >/* Run the system dependent event loops */
> >void SDL_PumpEvents(void)
> >{
> >  if (!SDL_EventThread) {
> >    SDL_VideoDevice *video = current_video;
> >    SDL_VideoDevice *this  = current_video;
> >
> >    /* Get events from the video subsystem */
> >    if (video) {
> >      video->PumpEvents(this);
> >    }
> >
> >    /* Queue pending key-repeat events */
> >    SDL_CheckKeyRepeat();
> >
> >#ifndef DISABLE_JOYSTICK
> >    /* Check for joystick state change */
> >    if (SDL_numjoysticks && (SDL_eventstate & SDL_JOYEVENTMASK)) {
> >      SDL_JoystickUpdate();
> >    }
> >#endif
> >  }
> >}
> >
> >int SDL_WaitEvent(SDL_Event * event)
> >{
> >   while (1) {
> >      SDL_PumpEvents();
> >      switch (SDL_PeepEvents(event, 1, SDL_GETEVENT, SDL_ALLEVENTS)) {
> >        case -1: return 0;
> >        case 1:  return 1;
> >        case 0:  SDL_Delay(10);
> >      }
> >   }
> >}
> >
> >So this is even worse. It has a built in polling every 10ms.
> >
> Hi
> 
> As I say before SDL is Simple DirectMedia Layer that was design to work 
> on many enviroment.
> Event code was create also for work on no-threaded system ( Windows 
> ???? ) and with single thread program. In this role work great but it 
> doesn't mean its good solution :(

But especially for non-threaded system you would need a select like
construct.

> Some time before Bob Pendelton fight with this problem and he
> creatae thread based event code (see:
> http://gameprogrammer.com/game.html )

Bob is a lot wiser than the SDL people by using a condition
variable. If you have condition variables and can use threads (and
both are AFAIK part of SDL) these are superior to polling. His FE
(fast events) looks a lot like classical select. Select here takes the
role of SDL_CondWait.

> we can use his code ( is small see attach ) and write somthing like :

This is what I outlined above. It will work. It _should_ also not
crash freeciv.

> But when I use it I can't make debug with gdb :(

Because gdb doesn't support MT? Welcome to the wonderful world of
MT. You also won't get MT core dumps btw AFAIK on some OSs.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Python is executable pseudocode. Perl is executable line noise"
    -- Bruce Eckel



[Prev in Thread] Current Thread [Next in Thread]