whenever I run small number of clients let say 100 to 150 kill signal from the server is working fine (here kill signal is send by the server to the client through the pid of the client process(at pause state).) when I m running above 150 client process kill signal from server is not working efficiently.
In short I mean to say kill signal is not working for heavy traffic of client is there any reason for it ?
Your issue is not heavy traffic, but loosely written algo, that works fine for few steps, but doesnt always work.
When the server sends the kill(PID, signal), it shall always reach your clients, with corresponding PID, and the designated signal handler will work, always
The problem is "timing fault".
The only exception is when the signal for which the pause statement waits has already passed, even before the client executed the pause() statement
This is a very common phenomenon in case of a heavily threaded environment.
Solution:
Modify your code to check if the designated signal has already occurred, if yes, come out of this user defined pause state.
"The only exception is when the signal for which the pause statement waits has already passed, even before the client executed the pause() statement" This not happening In my Algo kill signal will go to that client only which are in pause state or pid of client will not given to the server until the client goes to pause state.
kill() signal has no integrated intelligence so as to target a paused system only it is only PID specifc and not event specific
You will have to imbibe in your code a mechanism that allows ur code to check, if the signal has already occured
You need to remove the pause() statement, and include a similar intelligent mechanism.
pause is cool, only when you are sure of the fact the a signal will come only after a particular event, which in case of threads is difficult to predict.
Scheduler may forward any process, so dont count on the code complexity to decide as to what comes first!!!
There are two tasks with specially distinguished process IDs: swapper or sched has process ID 0 and is responsible for paging, and is actually part of the kernel rather than a normal user-mode process.
The other is the famous init process with PID 1, and is primarily responsible for starting and shutting down the system.
The swapper basically will fork() the PID 1 process, the first user-process.
