Forks, Threads, shared memory in a Game

Forks, Threads, shared memory in a Game

Post by William Garriso » Mon, 16 Jun 1997 04:00:00



I'm writing a 'stateless' game that runs of HTTP, and I need
to do the usual server fork()ing thing, BUT...

The game has megs of static structures.
It has LOTS of linked lists of little structures.
The children will spend >70% of their time on socket I/O.
fork() duplicates megs of data that it does not need to.

It seems silly to use shget for each allocation of an
object in the linked list -- this seems like it would
get messy, and use lots of lists.
Q: How many calls to shget() can I do? (the linked lists
   will be destroying and recreating things alot). And
   is there a limit on how much?

This looks like a good case for a thread -- it would save
alot of IPC semaphores and shared memory problems...

Any thoughts? Thanks in advance.

 
 
 

1. memory leaks by shared memory and fork

Hi,

i've a problem with a server-program. It consums memory and never release
the memory. Even if i kill the program the memory never comes back.

When the program starts, it allocate a bunch of RPC-client connections, and
stores them in an shared-mem region (created with mmap() PROT_READ |
PROT_WRITE, MAP_SHARED | MAP_ANON ).
When my program receives an RPC-call it calls fork(), the child takes one of
the free connections from the pool, mark it as busy, and route the RPC via
the connection to another server.
Before the child process terminates (via exit() ) it marks the connection as
free.
The parent process runs in an loop, and waits for new RPC-calls or SIGCHLD
when a child terminates.

That what makes me "unhappy" is, that every fork consum 4kb, and the memory
is never released. There is no malloc (new) after the fork.
The child only read/write the mmap-memory.
There is only a special handling for broken RPC-connections. Then the server
(in the child process) replace the broken connection with a new one. But
this happens very rare.

Has anyone a good idea whats the reason for this behavior?

Okay, the system is a RH8.0 standard installation. Nothing is patched or
changed.
I get the same results on RH7.2 or SuSE 7.3. Under Solaris 9 happens nothing
and the program works as designed!

best regards
Joerg

2. s390 update (3/9): listing & kerntypes.

3. Shared Memory,Memory mapped files and Threads

4. xlock is not invoked from the menu, when xdm is running

5. Shared memory, memory mapped files and threads

6. DHCP kills kppp - please help

7. Saving FTP macros

8. Shared Memory Fork

9. Problem using fork, shared memory

10. Shared Memory Type Fork

11. fork, shared memory.