Subj : Re: pthread_mutex_lock throws an exception on receiving signal 15
To   : comp.programming.threads
From : Paul Pluzhnikov
Date : Tue Oct 04 2005 09:02 pm

"pankaj-startup" <pankaj.takawale@gmail.com> writes:

> I was under impression that "undefined behaviour" means call to
> particular unsafe function fails (in this case pthread_create)

Your impression is incorrect. I told you this before, but you
weren't paying attention :(  I'll repeat:

  the result of calling any of them (async-signal unsafe functions)
  in async-signal context is undefined: your program may appear to
  work, or it may crash, or hang, or it may melt your CPU.

> Then what should be in signal handler? -> cancel(set appropriate flag)
> all threads, & exit ?

You can't pthread_cancel(), and exit() is not async-signal safe either.
You can call _exit(), or you can tell some other thread that it is
time to clean up. Usually this is done via write(2) to a pipe on
which the "cancellation" thread is blocked, or a sem_post().

> Can you please give me some pointers why these few functions are Unsafe
> in the context of asyn signal handler?

Few? Most functions are unsafe. Many of them are unsafe because
they might call malloc. To understand why malloc(3) is unsafe,
study a sample implementaion in K&R, then ask yourself what would
happen if interrupt comes in the middle of malloc() and another
malloc is performed from within signal handler, while the first
malloc call is "suspended", and what will the first call do once
it resumes.

> I called exit(0) on recieving signal 15, and process terminated
> gracefully without dumping core.

You are invoking undefined behaviour again :(
Yes, it worked this time, but may not work the next time.

> If this is the case, why do people want to cancel threads before
> exiting?

Because people may have resources that need to be properly cleaned up,
database connections that need to be closed, files with buffered
output that needs to be flushed, etc. etc.

If you don't have any of this, then don't intercept SIGINT/SIGTERM
at all and let the system take default action, which will terminate
your process anyway.

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

.