Thread: delivering signals

  1. #1
    Registered User
    Join Date
    May 2008
    Posts
    5

    delivering signals

    Hi,
    Does anyone know how to prevent from delivering signal to process even after that signal was unblocked?

  2. #2
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    you could catch it and do nothing with it

    Code:
    signal(SIGINT, my_sigint_handler);
    ...
    void my_sigint_handler(int sig)
    {
      /* just return.  do nothing here */
      return; /* not really necessary, but just for clarity */
    }

  3. #3
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by maverick84 View Post
    Hi,
    Does anyone know how to prevent from delivering signal to process even after that signal was unblocked?
    The way you prevent delivery of signals is by blocking them. If you're unwilling to do that, you can't stop the signal.

  4. #4
    Registered User
    Join Date
    May 2008
    Posts
    5
    Thanks for your reply,

    of course, I can block the signal, but this signal can't be blocked all the time. After definited time it should be unblocked.

  5. #5
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by maverick84 View Post
    Thanks for your reply,

    of course, I can block the signal, but this signal can't be blocked all the time. After definited time it should be unblocked.
    Your requirements are not clear enough to suggest any specific solution.

    If you want to check pending signals every X seconds, for instance, then you can set up an alarm to go off after X seconds, then in the signal handler for this alarm, unblock the signals of interest. If signals are pending, they will immediately be delivered. Once they are delivered, you can block them again and set up a new timer.

    But without knowing more about your specific requirements that's as far as I can go.

  6. #6
    Registered User
    Join Date
    May 2008
    Posts
    5
    I have to stop application by sending signal to it. During application is stopped user shouldn't be able to sent any other signals to that application (other signals must be blocked). User can resume program by sending another signal to it. When program is running all signals must be unblocked. Signals which was sent when application was stopped can't be delivered when application is running

  7. #7
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by maverick84 View Post
    I have to stop application by sending signal to it. During application is stopped user shouldn't be able to sent any other signals to that application (other signals must be blocked). User can resume program by sending another signal to it. When program is running all signals must be unblocked. Signals which was sent when application was stopped can't be delivered when application is running
    It sounds to me like you're talking about inter-process communication (IPC), rather than signal handling. look into pipes and message queues, as those mechanisms would be better suited for the application you're describing.

  8. #8
    Registered User
    Join Date
    May 2008
    Posts
    5
    No, in this task I have to use signals rather than IPC...

  9. #9
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by maverick84 View Post
    I have to stop application by sending signal to it. During application is stopped user shouldn't be able to sent any other signals to that application (other signals must be blocked). User can resume program by sending another signal to it. When program is running all signals must be unblocked. Signals which was sent when application was stopped can't be delivered when application is running
    This sounds like when the app is in the "stopped" state, it's not really stopped, just doing nothing and ignoring all signals. If the application is truly stopped, there is no way to cause the signals which are delivered to it to be ignored -- they are simply deferred until the application starts again.

    So when you enter your stop state, you should:

    1. Unblock all signals and set their handlers to the ignore handler (SIG_IGN)
    2. Enter an infinite loop calling pause()

    Then, when the application is "unstopped:"

    1. Break the infinite loop
    2. Restore all signal handlers and masks to their original state

    You can't make a signal just "vanish." It is either blocked (and will be delivered once unblocked), or ignored.

  10. #10
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by maverick84 View Post
    No, in this task I have to use signals rather than IPC...
    is there a specific reason why IPC is not an viable option? is this a school assignment of some sort where you are supposed to be learning about unix signals? I would think that IPC would be ideal for your application, as it allows programs to communicate with, or "signal" one another.

  11. #11
    Registered User
    Join Date
    May 2008
    Posts
    5
    OK this problem is solved, but i have another one. How can I clear stdin buffer?
    I know that i can use function like this:
    Code:
    void dump_line( FILE * fp )
    {
      int ch;
      while( (ch = fgetc(fp)) != EOF && ch != '\n' )
        /* null body */;
    }
    but it works in case when in buffer is only one line. How to clean in when it's more than one line?

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Using signals between unrelated processes (C/Linux)
    By sauronnikko in forum C Programming
    Replies: 3
    Last Post: 06-29-2009, 04:20 AM
  2. A question about signals handling
    By smoking81 in forum Linux Programming
    Replies: 10
    Last Post: 10-01-2008, 03:38 PM
  3. kill & stop signals
    By ssharish2005 in forum C Programming
    Replies: 6
    Last Post: 02-18-2008, 02:04 AM
  4. keyboard capturing
    By xlnk in forum Linux Programming
    Replies: 4
    Last Post: 01-31-2003, 01:02 PM
  5. queued signals problem, C programming related
    By Unregistered in forum Linux Programming
    Replies: 3
    Last Post: 01-22-2002, 12:30 AM