FreeTDS Development Group

["Brian Bruns" <camber AT ais.org>]

I haven't been following this thread too closely, can someone give me a
quick summary on this?  I'd rather not have any thread primitives in the
library if we can avoid it even if it does mean implementing our own on
those platforms that don't have a suitable reentrant function. And if we
have suitable functions on different platforms (Tru64 has X, linux has Y,
HP/UX has Z) can we wrap them and use autoconf to test?

Brian 

> On Thu, Aug 29, 2002 at 11:03:23AM -0400, Castellano, Nicholas wrote:
> > The real problem is like this.  Say you have some other thread that does
> > something really bad, generating a SIGSEGV.  It just so happens that your
> > luck is bad, and at the time that the SIGSEGV was generated, vasprintf() 
> > has
> > installed its sigsegv() function to handle this signal.
> > 
> > Now, this other thread has entered sigsegv().  Even if it can determine
> > "Gee, I really don't belong here, this handler is really here to service 
> > the
> > thread doing the asprintf()!", what can you do about it at that point?
> > Maybe we want to dump core at this point.  But maybe there's another 
> > SIGSEGV
> > handler, temporarily replaced by the one in asprintf.c, and if we could 
> > only
> > figure out what that handler was, we could call it to get the correct
> > behavior.
> 
> I don't understand why all this talk about SIGSEGV handlers.  From man 2
> sigaction:
> 
>        According to POSIX, the behaviour of a  process  is  unde­
>        fined after it ignores a SIGFPE, SIGILL, or SIGSEGV signal
>        that was not generated by the kill() or the raise()  func­
>        tions.  Integer division by zero has undefined result.  On
>        some architectures  it  will  generate  a  SIGFPE  signal.
>        (Also  dividing the most negative integer by -1 may gener­
>        ate SIGFPE.)  Ignoring this signal might lead to  an  end­
>        less loop.
> 
> Anything depending on handling SIGSEGV will be platform-dependent anyway.
> 
> -- 
> berndfoobar AT users.sourceforge.net is probably better to bookmark than any
> employer-specific email address I may have appearing in the headers.
>   Vanity page: http://www.tsct.co.za/~berndj/