understanding shared memory Sender: Linux

Just some Perl-type discussion......(value = 2 cents :-) )

When you fork, you get an exact copy of the current process, (read "perldoc -f fork") and with Perl that means all the modules currently in use. If you "fork and exec", you can create a new process, but remember, with Perl ( and almost all scripting languages), they will NOT return memory which has been allocated to them, until they exit. They will just keep the memory in an "available pool" to reuse. So say you are at 16 meg when you fork, your forked process, under Perl, will also be 16 Meg. And even if you exec something smaller, it will hold on to that 16 Meg in it's memory pool.

You may get some very good Perl advice, if you post this question

It sounds like you need some "design advice" on handling objects and modules efficiently. You probably want to set up something like a small frontend to accept the connections, then fork to something else to handle each client, and add your modules(as needed) after the fork.

You also need to be aware of "pseudo-memory-leaks", where objects are left laying around, causing the main app to start accumulating memory. Just undef'ing an object will not always destroy it completely. There is a thing called "auto-vivication", and the "ref-count".

Most well designed Perl apps, reuse the same objects repeatedly, instead of attempting the "create, undef, create" cycle.

You will eventually get to the right solution....everything is possible in Perl.....it's just "finding it". You will find that it is probably the same way the mainstream c pop servers do it. Maybe look at the source code for pop3d ? Or go to http::cpan.org and look at the source code for

Net::Server::POP3

and see how they do it.

-- I'm not really a human, but I play one on earth.