[bf1942] Linux server status report: 2003-03-31

[Fredriksson, Andreas]

Andrew,

the CPU load comes from all the disk I/O and file parsing going on
at level load time.

There's not much to do about this except maybe providing callbacks to
some external root-uid process that can change the niceness of the
main bf1942 thread during loading. But that way clients will have to
wait longer before they can connect to the new map, so it's not
a perfect solution either.

Regards,
Andreas

-----Original Message-----
From: Andrew Chen
To: bf1942 at icculus.org
Sent: 3/31/2003 8:21 PM
Subject: Re: [bf1942] Linux server status report: 2003-03-31

At 05:20 AM 3/31/2003, you wrote:
>- The Linux server is compiled with gcc3 now, and this has uncovered
>   some pretty nasty bugs that were masked out by gcc2/msvc. I'm still
>   sorting out library issues and how we are going to distribute the
>   package. Would a completely static version be acceptable for people
>   with older distributions?

Hehe, I called it, didn't I?  :)

How about a static version and a dynamic version?  That way we can
choose 
which one we want to run.  The solution should NOT be maintaining both a

gcc2 and gcc3 build, though.

In other news...
Is it possible to make the server NOT obliterate the CPU on 
mapchange/daemon restart?  This applied in win32 as well.  On restart,
it 
pretty much sucks up all available CPU time, meaning that you can only
run 
1 BF server on a single CPU system.