Subj : Re: How to manage time-slicing in Pthreads programs?
To   : comp.programming.threads
From : jd
Date : Mon Feb 21 2005 06:13 pm

> > It's not like I think that signals are a great way for introducing
> > asynchronicity in a single-threaded programs. But what to do with events
> > which generate SIGILL, SIGABRT, SIGFPE, SIGKILL, SIGSEGV, SIGTERM,
SIGBUS
> > and possibly some more? Ignore or force OS to act always the same way
(eg.
> > terminate with core dump)? They are not "GUI-events", which are like
other
> > signals, SIGIO, SIGINT or, most noticeably, SIGUSR1.
> >
> You brought up a synchronous exception which is something completely
different.
> Unix chose its signal mechanism as the method of notification.
Unfortunately
> they're usually not very useful as you have to have the compiler and OS
cooperate
> with the right information in siginfo pointing to an instruction that you
can
> somehow relate to something you did in the program source.  It's done.
Some
> compilers are set up to trap certain arithmetic exceptions because that's
the
> mechanism the hardware provides.  SIGSEGV is difficult to use properly in
a
> C program.  Most people using it are using it wrong especially when they
think
> they can recover from some error.  It's on my list of things that indicate
> someone doesn't know what they're doing.  Ditto for SIGILL and SIGBUS.
>
> The SIGKILL, etc are more examples of the asynchronous signaling.  Same
argument
> as ^C.  It's not the only way you can do things.  Every seems to be
ignoring the
> obvious example of MS windows and other OSes that don't have signals and
seem to
> be otherwise perfectly functional.

I've been thinking for a moment and, although sadly, must say "Yep, you're
right".

Damn, I'm ambitious, quarrelsome and not experienced enough. That makes life
really hard sometimes, especially on usenet :)

JD

.