in reply to choosing threads

I thought of using fork. but in case I have 100 files, I must have to fork 100 times, where one process reads one file at a time and pumping data to a single(same) client. When the second client connects it would be a mass fork of again 100 processes.

Maybe I'm the only one who has trouble understanding this paragraph as others have answered without quesioning it, but it's not at all clear to me why you feel you need to "fork 100 times" in order for "one process reads one file at a time and pumping data to a single(same) client"?

Essentially, it is not clear from your post what you trying to do, but reading between the lines, it may be something like:

  1. Open a listening socket:
  2. When a client connects, select one of 100 hundred files and send it to that client; disconnect.
  3. Repeat.

If that's an accurate picture of the requirement, then it can easily be satisfied with either fork or threads, and without the 'mass spawnings' that you seem to think are involved.

If that is an inaccurate description of then you need to clarify the actual requirements before you will get useful answers.

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".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^2: choosing threads
by targetsmart (Curate) on Feb 20, 2009 at 05:47 UTC

    It has to be
    1. Open a listening socket:
    2. When a client connects, I need to pump the content of all the 100 hundred files to the client and disconnect.
    NOTE: when reading from files, I will read a packet(collection of events delimited by \r\n) from file 1 and pump into the socket, then read a packet from file 2 pump into the socket, it goes on for all the 100 files as long as there are packets in the file.
    It won't be always file1 and file2 , it can be file1, file100, file10, ...(asynchronous).
    This pumping should occur in parallel.
    Actually I am trying to simulate a C program which solved the above problem using threads effectively.
    3. Repeat.
    I hope that I have given some clarity of my problem.
    Vivek
    -- In accordance with the prarabdha of each, the One whose function it is to ordain makes each to act. What will not happen will never happen, whatever effort one may put forth. And what will happen will not fail to happen, however much one may seek to prevent it. This is certain. The part of wisdom therefore is to stay quiet.
[reply]
      I hope that I have given some clarity of my problem.

      Clearer, but this "It won't be always file1 and file2 , it can be file1, file100, file10, ...(asynchronous)." still needs clarification.

      Why would the order you read from the files vary? (What do you mean by asynchronous? (I know what the word means:))

      Also, are you likely to have concurrently connected clients, or will it be a one client at a time affair?

      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".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        Rather than using the word asynchronous I must have used random.
        Basically what I have is this.
        I have captured event packets related to a particular call(voice call) from a PBX. For a call if there are totally 200 events reported by PBX, all the 200 events will be logged in a file. Similar to that there would be lot of calls happening via that PBX and the PBX would have sent lot of event packets. I have carefully captured all the call events and segregated them into files(a file will contain a single complete call's event packets).
        Now I would want to simulate the PBX to an external program(because making that many live voice calls to do load testing is costly and any programmer wouldn't want to do that), the external program shouldn't at any time know that I am not PBX, so I have taken enough care on authentication open and close, event packet delimiters etc. but In real time; the calls would have come randomly(asynchronously). I want to simulate the same amount of randomness in the call events depending one configuration in a hash like 
        %simulateconfig = (
file1 => 200, # this file events have to cycled 200 times
file2 => 20, # this file events have to be cycled 20 times
...
);

        [download]

        for that I have changed the timestamp of events, unique id of the call, etc to perfection.
        Finally what I have left to complete is this randomness that is where the key is.
        That is why I have decided to go for threads. because I thought that in fork I might waste some time in creation of process and resources associated with that, so i decided to go for threads, since they are lightweight compared to fork.
        I can do this in C with posix threads. but it will take a considerable amount of time to write code.
        I want to do this in perl, because maintenance, configuration, debugging, scalability becomes easy(in terms of time and efforts).
        That is all I have about the definitions with the problem. Any suggestions to solve this problem and simulate calls(call events) in perl is valuable to me.
        UPDATE
        Also, are you likely to have concurrently connected clients, or will it be a one client at a time affair?
        yes I have more than one client connected to me(I have to serve concurrently).
        Vivek
        -- In accordance with the prarabdha of each, the One whose function it is to ordain makes each to act. What will not happen will never happen, whatever effort one may put forth. And what will happen will not fail to happen, however much one may seek to prevent it. This is certain. The part of wisdom therefore is to stay quiet.
[reply]
[d/l]

In Section Seekers of Perl Wisdom