in reply to Re^3: Handling multiple clients
in thread Handling multiple clients

both processes showed up with the same size.

Yes, but which size? top shows a lot of information. If you don't know what the columns mean, your interpretation can be wildly wrong. Running the following very naive and simple program on my laptop (Linux PPC with a 2.4 kernel) and looking at top shows two processes of about 40 Mb apiece -- but the amount of shared memory for each process is exactly the same.

#!/usr/bin/perl use strict; use warnings; my @foo; $foo[10000000] = 1; fork and sleep 10; sleep 10;

As for the question of why Perl's ithreads are worse than forking, having seen the ithreads code only a couple of times and not being an expert on memory management by any means, I suspect Perl doesn't take advantage of the COW features of decent kernels. I make this guess because I don't know of any way that Perl could hint to the kernel to share specific memory pages.

Replies are listed 'Best First'.
Re^5: Handling multiple clients
by BrowserUk (Patriarch) on Sep 05, 2004 at 09:49 UTC

    There is always another way to skin a cat.

    Rather than have every thread share the 2GB of data, I would create the server threads before loading it.

    Only the the main thread would have a (non-shared) copy of the 2GB, but would share the requests and replies with the server threads.

    The advantages. No signals, reapers, select or constantly renewing processes.


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
      This sounds more like what I was after to begin with. Any pointers to code that would achieve that?

        Re: Handling multiple clients (use threads) :)


        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail
        "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon