Very Computer

Hi,
Is there any way one can ensure that the signal() function on the UNIX
platform works in a Multithreaded situation ?
Since signal() is not a thread safe call, How do we see to it that -
when there are many threads spawned and one thread say T1 encounters an
error in the execution and gives a SEGVSIGNAL and other threads should
not be affected by this?

Thanks.

Sent via Deja.com
http://www.deja.com/

[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]

Generally, this is impossible.

While you can catch SIGSEGV in a MT application, SIGSEGV is usually
an error condition caused by datastructure inconsistencies.  Once that happens,
everything in the same address space, i.e., all data, all threads, is suspect.

The program should terminate as there is no way to recover.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

This kind of thing works SO MUCH better on NT, it's a disgrace for Unix.
Exceptions on NT can be caught on a per-stack frame basis, that is, each
arbitrarily nested stack frame can set up an exception handler and decide to
process the exception, ignore it (as long as the exception is recoverable),
or pass it on. If you wanted to, you could probably even have seperate
worker threads with the same thread function that handle the same exception
differently.

SEH on NT is such a big plus. If Unix had something remotely as powerful, NT
would have had it a long time ago. Global signals are a poor hack, even in a
single-threaded environment.

Quote:> Hi,
> Is there any way one can ensure that the signal() function on the UNIX
> platform works in a Multithreaded situation ?
> Since signal() is not a thread safe call, How do we see to it that -
> when there are many threads spawned and one thread say T1 encounters an
> error in the execution and gives a SEGVSIGNAL and other threads should
> not be affected by this?

> Thanks.

> Sent via Deja.com
> http://www.deja.com/

Quote:> This kind of thing works SO MUCH better on NT, it's a disgrace for Unix.
> Exceptions on NT can be caught on a per-stack frame basis, that is, each
> arbitrarily nested stack frame can set up an exception handler and decide to
> process the exception, ignore it (as long as the exception is recoverable),
> or pass it on. If you wanted to, you could probably even have seperate
> worker threads with the same thread function that handle the same exception
> differently.

I admit I don't know a lot about NT, but I was under the impression
that all threads in a process shared the same address space there, as
in Unix. Am I wrong about that?

If not, then it seems to me that a memory error committed by one
thread would have the same kind of process global effect it would for
a thread in a Unix process. If that's the case, then trying to handle
SIGSEGV is a pointless excercise. Once memory's been *led, the
best thing you can do is core dump, analyze the core, and fix the
problem so it doesn't happen again.

Quote:> SEH on NT is such a big plus. If Unix had something remotely as powerful, NT
> would have had it a long time ago. Global signals are a poor hack, even in a
> single-threaded environment.

So does NT manage to isolate memory on a per-thread basis (what's the
point of threads if it does that)? If it doesn't do that, then global
signals are not a poor hack, they're the obvious response to a
globally significant error.

You can block signals in all threads but one, which catches signals
you're interested in. It can then signal the other threads as
appropriate.

Joe

Any multithreading system uses the same virtual address space for all
threads in the same process, that's the definition of multithreading.

You are right that, say, access violations caused by incorrect memory usage
(which in a multithreaded system can be symptoms of incorrect
synchronization on top of any other memory problem) can not be prevented by
SEH, but they can be dealt with gracefully. In the case of access
violations, I would agree that it's hard to imagine a way in which to
recover gracefully from a "local" access violation (in NT you normally do
this to gracefully clean up all pending resources - release semaphores you
have in use, close all open files, reinstall database integrity etc before
terminating. This is actually very useful to ensure predictable behavior of
your application under any circumstance).

Point is that in NT you use the scheme to handle *all* exceptions. Assume
that some worker thread encounters a division by 0 trap. This does normally
not impact the rest of the system, only indicates some invalid computation
for whatever reason. NT lets you deal with this exception in the worker
thread, so you can somehow handle the error there and leave the rest of the
system intact.