[bf1942] Multithreaded?

[Killing]

Q3 does do lookups in the server. I've traced it doing the master
lookup.

    Steve
----- Original Message ----- 
From: "Scott Brooks" <blaze at fragz.ca>
To: <bf1942 at icculus.org>
Sent: 17 December 2002 06:20
Subject: Re: [bf1942] Multithreaded?


Also, multithreading really helps when the threads are relativly
independent.  In a webserver the all the threads could care less what
the other threads are doing for the most part.

Adding multithreading to a game (beyond something like io, or sound, or
other blocking calls) you will run into issues where you need to deal
with the case of when one client picks up a gun off the ground letting
the rest of the threads know it's gone.  Add lag into that and you can
get into a real mess of race conditions.

Also, I think q3 totaly ignores DNS and just uses their IP addresses.  I
don't think it does any DNS lookups at all.


On Mon, 2002-12-16 at 23:16, Ryan C. Gordon wrote:
> > Maybe not quite the place to ask this, but its a real simple question.
> > Is the BF server, or even client for that matter, multithreaded?  It
> > seems to be more common to games these days, with processor prices
> > dropping, multithreaded support in XP and such...
> 
> There is a seperate thread for socket i/o in the server. I can't speak for
> the client...might have a thread for input, but I haven't looked that
> closely.
> 
> To give you a quick breakdown of popular engines, biased by my experience
> with them:
> 
> 1) Unreal Engine: spins a thread for DNS lookups, since gethostbyname()
> blocks, and would stop the game dead until it gets an answer from the DNS
> server.
> 
> 2) Quake 3 (and variants, like Ritual's FAKK2 framework which was used for
> MOHAA) is single threaded. Looks like even the DNS lookups happen in the
> main thread. There is multiprocessor support where rendering is handled in
> a separate thread, but historically, this has reduced performance on Linux
> and/or caused instability (OpenGL in a seperate thread is always a
> dangerous proposition in my experience).
> 
> 3) Serious Engine: on win32, it spins a separate which then handles timed
> events and updates. Scary. Ripped it out for the Linux version, which is
> single threaded.  :)
> 
> Unix games that use SDL for audio will spin a thread that is used solely
> for feeding the audio device.
> 
> SMP is a delicate thing in games, since you need to have something that
> works equally well with or without it, performance will be very platform
> specific, and there's never enough development dollars for something that
> won't bring significant gains.
> 
> It's nice to have threads that are able to span CPUs, since this is a win
> in a general sense (write a webserver that has X threads and let the
> kernel sort them out), but specific support for multiprocessing is really
> more the domain of things like Photoshop filters...specialized
> applications that want a speed boost but don't care about framerate and
> exercising extreme control over the system. But feel free to disagree with
> me on that point.
> 
> Now someone go write patches for "top" and "ps" so that people don't think
> they've got three copies of bf1942_lnxded running!  :)
> 
> --ryan.
> 
-- 
Scott Brooks <blaze at fragz.ca>