I have a program in c where I want to do some calculations which may or may not take a very long time. It is hard to know beforehand how much time the calculations will take. The program has a cli so right now I usually do something like this

./program
do calculation 243

and it starts calculating. If I want to cancel it because it takes to much time I do ctrl c and restart the program with another calculation. Now I would like for the program to cancel the calculation itself after either q has been pressed or for example 10 seconds has passed.

I have found a way which seems to do what I expect using pthreads. I'm however wondering if this is recommended or if there are for example any memory leaks or other things that can happen.

The following is my code

void *pthread_getc(void *ptr) {
    char c = '\0';
    while (c != 'q')
        c = getc(stdin);
    pthread_cancel((pthread_t)ptr);
}

void *pthread_sleep(void *ptr) {
    sleep(10);
    pthread_cancel((pthread_t)ptr);
}

void pthread_cancellable(void *(*ptr)(void *), struct arg *arg) {
    pthread_t thread_main, thread_getc, thread_sleep;

    pthread_create(&thread_main, NULL, ptr, (void *)arg);
    pthread_create(&thread_getc, NULL, pthread_getc, (void *)thread_main);
    pthread_create(&thread_sleep, NULL, pthread_sleep, (void *)thread_main);

    pthread_join(thread_main, NULL);
    pthread_cancel(thread_getc);
    pthread_cancel(thread_sleep);
    pthread_join(thread_getc, NULL);
    pthread_join(thread_sleep, NULL);
}

the idea being that both pthread_getc and pthread_sleep can cancel main, and once main is cancelled so are these two. Then I simply call pthread_cancellable where the first argument is a function doing the calculation and the second argument is the arguments to the calculating function.

Can something go wrong with memory leaks here or something else? Is there an easier/better way to this in c?

What happens if main is cancelled two times and if a thread gets cancelled when its already done?

CodePudding user response：

Can something go wrong with memory leaks here or something else?

If the program is going to terminate after aborting the computation then there is no issue with memory leaks. The system does not rely on processes to clean up after themselves -- it will reclaim all memory allotted to the process no matter how the process used it.

But your code violates the #1 rule of pthread_cancel(): never call pthread_cancel(). And although monitoring stdin for a q keystroke could work, that's a bit odd, and it potentially gets in the way of using stdin for something else you want to add to your program later.

Is there an easier/better way to this in c?

Yes. In the first place, if the objective is simply to terminate the program at timeout / user interrupt, then do that. That is is, have any thread call exit() when you want to terminate. You do not need to cancel any threads for that.

In the second place, I don't see what is gained by implementing a custom keyboard action (type 'q' to abort) when the standard interrupt signal sent by Ctrl-C works fine, and you even get the latter for free. If you want or need to perform some kind of extra behavior in response to an interrupt signal (before or instead of terminating), then register a handler for it.

There are multiple ways you could implement the early termination behavior, but here are outlines of two I like:

No-frills abortion upon timeout (or Ctrl-C):

• Only the program's initial thread is needed.
• Before it launches the computation, it creates and starts an interval timer (timer_create()) to count down the timeout. Configure the timer to raise SIGINT when it expires.

That's it. You get termination via the keyboard (albeit with Ctrl-C as you already do, not 'q') and the same termination behavior as far as an external observer can see in the event of a timeout.

optional addition 1:

If desired, you can install a handler for SIGINT to get extra or different behavior upon cancellation than you otherwise would. Note, however, that there are significant limits on what a signal handler may do. For example, maybe you want to emit a message to stderr (use write(), not fprintf() for such things), or you want to exit() with non-zero status instead of terminating (directly) because of the signal.

optional addition 2:

If the program reaches a point where it is not finished but it no longer wants to be terminated when the timeout is reached then it may at that point use timer_delete() to disable the timer.

With-frills abortion upon timeout (or Ctrl-C):

If you want to perform work in response to abort of the computation that is unsuited for a signal handler (too much, needs to call functions that are not async-signal-safe, ...) then you need a thread to do that in, and additional control structures and mechanisms. This is one way to do it:

• Create and initialize a mutex, a condition variable, and a flag of type sig_atomic_t, all at file scope. The contract for these is that the flag may be accessed (read or write) only by a thread that currently holds the mutex locked, and that the mutex is the same that will be associated with all waits on the CV.

• Install a signal handler for SIGINT that

  1. locks the mutex
  2. Provided that the flag does not indicate completion, updates it to indicate cancellation
  3. unlocks the mutex
  4. broadcasts to the CV

• The last thing the computational thread will do after completing its work is (with the mutex locked) set the flag to a value indicating completion, and then broadcast to the CV.

• The initial thread will then do this:

  0. Setup as described in the previous points
  1. lock the mutex
  2. Create / start an interval timer (timer_create()) that raises SIGINT when it expires, after the chosen timeout period.
  3. Start the computational thread
  4. loop while the flag indicates ongoing computation. In the loop body
     • perform a wait on the CV
  5. The computation having either completed successfully or been canceled at this point, perform whatever final actions are appropriate and then terminate, either by returning from main() or by calling exit().

That's still pretty clean, gets you both timeout-based and keyboard-based cancellation (albeit the latter with Ctrl-C instead of 'q'), puts all the cancellation handling in one place, and requires only one thread in addition to the computational one.

optional addition: abort in response to 'q'

Although I do not recommend it, if you really must have that termination by typing 'q', then you can set up another thread that monitors for that keypress / character, and performs a raise(SIGINT) if it sees it.