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
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.
> > 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?
You can block signals in all threads but one, which catches signals
you're interested in. It can then signal the other threads as