Re: SIGALRM Signal getting lost - HP UX

This is a discussion on Re: SIGALRM Signal getting lost - HP UX ; This is the signal Handler we are using. We just iterate over our Process Array and set some counters in a shared memory area. static void timer_aufziehen( void ){ for ( i = 2; i if ( p_verwalt[ i ].pid ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Re: SIGALRM Signal getting lost

  1. Re: SIGALRM Signal getting lost

    This is the signal Handler we are using. We just iterate over our
    Process Array and set some counters in a shared memory area.

    static void timer_aufziehen( void ){
    for ( i = 2; i < lvs_obj_count ( "PROCESS" ); i++ )
    if ( p_verwalt[ i ].pid != 0 )
    {
    if ( timer_array[ i ] > 0 ) timer_array[ i ]--;
    if ( timer_array[ i ] <= 0 )
    {
    timer_array[ i ] = p_verwalt[ i ].max_p_timer;
    if ( timer_array[ i ] != 0 ) anstossen( i );
    }
    }

    alarm( 1 );
    anstossen();
    }

    The function anstossen(); just calls semop( sem_id, &sem_op, 1 ) to
    increment the semaphor of this process.
    Is it possible that the semop needs more than 1 second to execute?
    I will try calling the alarm function at the very end of the signal
    handler.

    Thanks
    Michael Kaes


  2. Re: SIGALRM Signal getting lost

    > Is it possible that the semop needs more than 1 second

    It depends what the operation is in the &sem_op structure, though
    non-blocking operations (ie. incrementing the semaphore value) should
    be very fast. On the other hand, the syscall itself does offer the
    opportunity for the OS to schedule other processes, and on a very
    (very) busy machine, it is possible to suspend a process for a second
    or more I would think. The semop itself may make other processes
    candidates for running; I don't know enough about HP-UX scheduling
    policies or the design of your system to predict whether that could
    take a second or not...

    It would be wise to put the alarm(1) at the very end.

    Cheers,
    -nick


  3. Re: SIGALRM Signal getting lost

    I will try this and hopefully this will solve my problem.
    Usally the Process is working for 3 to 5 Days before the signal gets
    lost.
    So i will see the results in a week.


    Thanks
    Michael Kaes


  4. Re: SIGALRM Signal getting lost

    Michael Kaes wrote:
    > Usally the Process is working for 3 to 5 Days before the signal gets
    > lost. So i will see the results in a week.


    Fingers crossed

    I *think* that strictly there is still a race condition even if you call
    alarm as the very last thing in your handler - you just can't guarantee
    that the handler exits and the signal is unmasked before the alarm goes
    off (under busy conditions).

    A better solution might be to use an interval timer (see man
    setitimer(2)). These (can) restart themselves automagically, so there's
    never a race condition - though you might "miss a tick" if your handler
    takes a long time.

    --
    Cheers,
    -nick

  5. Re: SIGALRM Signal getting lost

    > So i will see the results in a week.

    How's it going? :-)

    -nick


  6. Re: SIGALRM Signal getting lost

    It looks pretty good. The process is now up for 11 Days and there are
    no problems so far. Putting the alarm() call to the very end of the
    signal handler made it. Although i still do not understand why the
    programm could not recover from a lost signal. Because after the first
    lost signal a kill -14 made the process just run for a few seconds.
    But anyway thanks for the help, i hope i do not have anymore problems
    with this, because very soon this system is going to be productive and
    a hanging process would be very bad.

    Thanks a lot
    Michael


  7. Re: SIGALRM Signal getting lost

    I don't know much about your system, but it would take a serious
    "blockage" to cause the signal handler to take more than a second (and
    hence lose its own signal). It may be that the circumstances that
    caused the loss of the first signal are persistent (or very periodic),
    so that when you send a SIGALRM by hand, you still only get a few ticks
    before another is lost. (But I agree it's suspicious)

    Using setitimer would be safer. It might only be a small code change
    if you're lucky.

    Cheers,
    -nick


  8. Question Re: SIGALRM Signal getting lost

    I have similiar problem.
    But in my case
    I start of the timer in main.
    and I have it at the end of the function

    extern "C" void handleSIGALRM(int)
    {
    signal(SIGALRM, handleSIGALRM); /* reset signal handler */
    printf("\nalarm!!! resetting. . .%u\n", counter);

    updateTotTime((unsigned int)clock());

    counter++;


    alarm(120);
    }

    the problem is that if i use lets say 18000 for clock (5 min)
    it never hits the alarm..
    in case of small values
    120 etc
    works fine...
    any ideas?

+ Reply to Thread