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

[Andrew Chen]

At 11:28 AM 3/25/2003, you wrote:
>--On Tuesday, March 25, 2003 8:43 AM -0800 Andrew Chen
><achen-bf1942 at divo.net> wrote:
>
> > At 02:26 AM 3/25/2003, you wrote:
> >> - Move to the gcc-3.x compiler
> >
> > Good Morning.
> > Just curious -- is this wise?  The existing server has been bit by
> > several optimization bugs.  Wouldn't moving it to 3.x be simply asking
> > for more issues?
>
>Could that be because the gcc crew tend to put more effort into the 3.x
>code line, so getting optimizer bugs fixed is more likely there?

Possibly, but IMO it's just adding more variables into the mess of debugging.


> >> - Internal code restructuring
> >
> > Does this include making the server NOT execpv() itself on mapchange? :|
>
>Was this a hack to deal with memory leaks?

I wouldn't doubt it.  I remember Ryan mentioned something about the server 
saying a message "YOU MUST RESTART THE SERVER TO CHANGE MAPS" when he tried 
to force the program to loop back to the beginning on a map change.  I 
guess there is a lot of sloppy programming in there or something.


>Along the same lines, please document what's going on with the server
>settings files. When are they written to disk, and why are their
>permissions getting changed? This makes it difficult to manage those files
>remotely while the server is running.

File permissions don't exist on Windows (or at least most programs don't 
care about them on NTFS), so when they open and close files, they probably 
use some flags that don't have effect on Windows but have some flunky 
effect on *NIX.

The whole idea of writing the files to disk at the end of map changes and 
stuff is to save the server state (like the current map it's about to run) 
because, remember, the server pretty much kills itself and starts from 
scratch.  The only state information it knows about are what's in those 
config files.

I wonder how many problems they could fix at once if they cleaned up the 
code enough that the server did not have to execpv() itself...