Re: exception handling around a signal handler



On Aug 27, 6:33 pm, Ulrich Eckhardt <dooms...@xxxxxxxx> wrote:
This can't work. The problem is that signal handlers are executed in the
context of a thread that is simply interrupted wherever it was. It could be
in the middle of an action that is otherwise (as far as e.g. threads are
concerned) atomic but the handler will be called nonetheless.

Now, there are basically two things you could do:
1. Use a flag.
The flag would be of type sigatomic_t (or somesuch) and you would need to
check it in the 'main' loop communicating with the child process.

I have considered this, but from my point of view, this won't work
either. If i have 200 lines of code that work with the child process
from the parent, just checking a flag is not going to be efficient. I
would have to insert

if (flag == 1)
return 0;

after every line of real code that works with the child process?

Besides the many lines of code currently within the main program block
not being atomic, it would be very hit and miss. I would also have to
rely on some mechanism of setting a sigalarm to fire before many of
the code blocks, since many parts actually work with waiting on system
calls that rely on the child process, being byte range locking,
semaphores and named pipes as part of the IPC to break the app from
deadlocking forever.

2. Use a dedicated thread to wait for signals.
The used function is sigtimedwait(). From there on, you can use whatever is
necessary to signal to the other thread that the child-process has died.

I have not done any thread handling, but would the main thread not
need some sort of periodic check of a mutex to verify the resource
given by the second thread handling signals? Is that not going to have
the same implications as the first point above with checking status
periodically to make sure it can keep going?


Under no circumstance can you pull the structure from under the main loop in
the signal handler, because you have no way to detect where it is currently
in the code.

Uli

Simon

.



Relevant Pages