in reply to Re: choosing threads
in thread choosing threads


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.

Replies are listed 'Best First'.
Re^3: choosing threads
by BrowserUk (Patriarch) on Feb 20, 2009 at 06:12 UTC
    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]
        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.

        If that's your only reason for considering threads for this, use fork instead. Perl's threads are not lightweight.

        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]

In Section Seekers of Perl Wisdom