I'm having a problem doing signal handling so I post this thread to see if I could get help.
I want asynchronous signal handling, that means when I'm processing a signal (signal 1), if the same signal comes (signal 2) that signal (signal 2) shall be processed; and moreover, the remain instructions of previous signal handler (signal 1) shall not be executed (or do nothing).
My problem is that I cannot discard remaining instructions from a previous signal.
As far as I know there's no way to cancel a signal that's already happened in that fashion. Your code would need to explicitly check whether another signal has happened at the critical point before it writes changes or what have you. A semaphore perhaps could be used to communicate this information; it'd pretty much have to be a semaphore ala sem_wait, that being almost the only signal-safe IPC.
With signal1 and signal2 did you mean the various instances of the signal of type <T>? If so, I don't understand the point of stopping the instructions that the first instance of the signal was processing and then to continue with the second instance of the same signal of type <T>.
If there are 'n' instructions to be processed when a signal is delivered and 'm' ( m <=n ) has been already processed, why the current set of remaining instructions should not be processed and the whole set of 'n' instructions to be processed afresh?
Thank you all Corona688 and matrixmadhan for your replies,
Because I have 2 applications and need to make communication via files and signal.
The first application shall write some files then send a signal to the second application telling the second to processes and then delete those files.
The problem is that, when the second is processing those files, the first one may throw new files and signal (the goal is the second gets latest data); therefore the second might delete new files which leads to lost of data or to be consistent.
So I hope that, I could, when a signal comes the second restarts processing those files (and discard instructions from previous signal action). I know this is not nature of signal handling.
(I know that I can make it synchronously by making the second send back a signal to the first to tell that it is ready to receive new signal, for example).
Well, you can't cancel signals that way. How about blocking them instead? You can make a signal wait in a queue until you're ready to deal with it with sigprocmask.
I have thought of blocking signal, but the problem is that the first application may throw new files while the second application is doing signal handing (and therefore delete those new files - after a file is processed, it is deleted); so I wanted when new signal arrives the second application would restart processing and discard previous actions.
After all, I found that my problem could not be solve asynchronously by signal like that because there are too much work need to done in handing a signal (I know that I could make it synchronously by getting back acknowledge from the second application - but I seem a little expensive). I might have to chose another approach.
I see a potential problem (rare) with this approach, what if, when a file is being processed, signal 2 (2nd instance) is passed, since its blocked it will have to wait, while the first file is still being processed and if there are multiple instances of signals being queued ( due to the reason they are blocked ) ... that could be when there is an application bug that is indefinitely processing a file, without completing the signal handler, or closing a filehandle via possible stale NFS.
All these will have end up in having multiple signals in state " that are yet to be delivered "
---------- Post updated at 09:40 AM ---------- Previous update was at 09:34 AM ----------
Correct me if am wrong somewhere, please
these are the sequence of actions
first application processing is processing a file
processing done, first application sends a signal to second appln to initiate processing
second application starts processing
before 2nd could complete, first completes processing and makes 2nd file ready for processing, signals 2nd application.
Now, should 2nd application delete the first file and start processing the second file?
If that is the case, there could be a shared memory segment between 1st and 2nd application and make 2nd application to listen for any data contents in the shared memory segment, and based on the filename in the data segment process only that file and discard others.
