Re^4: choosing threads

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.

Comment on Re^4: choosing threads Download Code

Replies are listed 'Best First'.
Re^5: choosing threads by BrowserUk (Patriarch) on Feb 20, 2009 at 08:38 UTC
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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^6: choosing threads by targetsmart (Curate) on May 11, 2009 at 09:04 UTC
Please enlighten me; why perl threads are not lightweight?. 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]
Re^7: choosing threads by BrowserUk (Patriarch) on May 11, 2009 at 12:14 UTC
Because, whereas in a compiled langauge each thread consists of little more than a set of cpu registers, a stack and an entry in the system scheduler tables; in Perl, you need those: plus a complete interpreter, plus per-interpreter copies of all non-entrant state. And as Perl began life as a single-threaded app, its internal state and control structures were never designed from the outset to be reentrant, which means there is of necessity, large volumes of per-thread duplication. 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."	[reply]