DCE Threads problem

[Erich Hochmuth]

Basically I have a multithreaded process and each thread has a set of signal handers registered. When I catch a SIGTERM I want to do some garbage collection before I shutdown the process. In the process of cleaning up some of my objects the process core dumps and I get a core file and a cma_dump.log file.

In the cma_dump.log file I get the following message at the top.
%Internal DCE Threads problem (version CMA BL10+), terminating execution.
% Reason: dispatch: no available VP (uniprocessor)

Can some one point me in the right direction as to where to find info on the various DCE Thread problems or what kind of scenario would cause the error that I am getting.

Thanks,
Erich

[Steven Gillard_2 · Accepted solution]

You've got to be careful handling signals in a multi-threaded program. Basically, you should have one dedicated "sigwait" thread, as described in the sigwait(2) man page:

Threads Considerations
The sigwait family of routines enable a thread to synchronously wait
for signals. This makes the sigwait routines ideal for handling
signals in a multithreaded process. The suggested method for signal
handling in a multithreaded process is to have all threads block the
signals of interest and dedicate one thread to call a sigwait function
to wait for the signals. When a signal causes a sigwait function to
return, the code to handle the signal can be placed immediately after
the return from the sigwait routine. After the signal is handled, a
sigwait function can again be called to wait for another signal.

In order to ensure that the dedicated thread handles the signal, it is
essential that all threads, including the thread issuing the sigwait
call, block the signals of interest. Otherwise, the signal could be
delivered to a thread other than the dedicated signal handling thread.
This could result in the default action being carried out for the
signal. It is important that the thread issuing the sigwait call also
block the signal. This will prevent signals from carrying out the
default signal action while the dedicated signal handling thread is
between calls to a sigwait function.

Regards,
Steve

[Wodisch]

Hi Erich,

CMA threads are NOT kernel threads, and hence lack some kernel internal data structures (only available once for the process, i.e. shared by its threads). For that reason you have to use so-called "jacket-routines" to encapsulate many system-calls. But some features are simply not "jacketable", like receiving signals :-(
So like the previous reply already read, you should use exactly ONE thread to do ALL the signals handling (and the rest of your threads to IGNORE signals), or you'll have to switch to kernel-level threads (not available for HP-UX10.x!). But the semantics of those are different, so your software has to ported - simple re-compilation is NOT sufficient...

FWIW,
Wodisch

[Adam J Markiewicz]

Hey, two VERY important things more:

1. All threads SHARE the signal handlers. You cannot instal handler per thread, but per process. However handler is called for one specific thread that handles the signal (little messy, but that how it's designed).

2. Signal is handled by only one thread, not all of them. It is not specified which thread will be chosen to handle the signal.

Concluding - it goes like this:

You register handler per process (only one function for each signal). When the signal comes, kernel gets the first thread that has that signal not blocked, and from this thread calls the handler that is registered for this signal. If its SIG_DFL it does defaults...


Adam

P.S.: I'm affraid it's too late, as the case is marked as solved. :(