I think the general solution is not to mix threads and fork. No good can come of it as the two mechanisms don't interact well.

I have to open up 300+ connections ... the process size grows to 2-3G

Hm. The following code starts 300 threads, each of which opens a connection to a local echo+1 server. The total memory usage is under 700MB:

#! perl -slw
use strict;
use IO::Socket;
use Time::HiRes qw[ sleep ];
use threads stack_size => 4096;  ## Tip: This significantly reduces th
+reads memory usage 

$\ = $/ = chr(13) . chr(10);

sub connection {

    my $svr;
    do {
        $svr = IO::Socket::INET->new( 'localhost:12345' );
    } until $svr;
    
    while( 1 ) {
        my $msg = int( rand 2**30 );
        my $reply;

        print $svr $msg;
        $reply = <$svr> until $reply;
        chomp $reply;
        warn 'Mismatch' unless $msg + 1 == $reply;
        sleep 0.001;
    }
}

async( \&connection )->detach for 1 .. 300;

sleep 1000;
[download]

The other memory saving tip is: only use those packages you need within your threads, before creating them. Load (require) anything that you only need in main after you've created your threads.

The threaded echo+1 server for your testing:

#! perl -slw
use strict;
use threads stack_size => 4096;
use IO::Socket;

$\ = $/ = chr(13).chr(10);

my $lsn = IO::Socket::INET->new( Reuse => 1, Listen => 1e6, LocalPort 
+=> 12345 )
    or die "Server failed to create listener: $^E";
print "Server listener created";
while( my $client = $lsn->accept ) {
    print "Server accepting client connection";
    async {
        while( my $in = <$client> ) {
            chomp $in;
            print $client $in + 1;
            printf "\rServer echoing client input: '%s'", $in;
        }
        print "Server shutting down";
        shutdown $client, 2;
        close $client;
    }->detach;
}
[download]

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this

In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

The reason for wanting to mix the two is that I have to open up 300+ connections to unique devices.

You don't tell what kind of connection that is, and what amount of code is involved interacting with those devices. Maybe you could make the connections into just (file)handles using pipe before forking, and IO::Select in the parent. If the creation and interaction with those devices is asynchronous (i.e. random wrt time), you could use an event based model using Event, EV or POE. That way your forked processes will be small enough, and will be returning claimed memory to the OS after execution. This is given with a lot of handwaving, of course; more of your code is required to give good advice.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

> But, I found that some of the code in this program uses globs and forks doesn't support globs

you mean typeglobs ? Can't you get rid of them?

Cheers Rolf

PS: Je suis Charlie!

Once the threads are closed, perl stays at that memory size until the process has exited.

Or until you join the threads, join for threads , it makes the memory reclaimable

I agree:   stick to one or the other.   Categorically speaking, the success of a multi-threaded application entirely depends on the ability of the various threads to synchronize their activities with one another when they have to.   All, in this case, within the operating context of a single Perl interpreter instance?!   The outcome, at the very best, would be “uncertain,” and I detest the word “uncertainty” in this context.