[haiku-development] Re: [RFC] sigaction SA_SIGINFO support

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 25 Jan 2010 19:45:44 +0100

On 2010-01-25 at 19:22:42 [+0100], Andreas Färber <andreas.faerber@xxxxxx> 
> Am 12.08.2008 um 01:37 schrieb Andreas Färber:
> > Haiku currently has BeOS-compatible signal handlers, which double as
> > basic POSIX-compliant signal handlers. Attached is a patch which
> > attempts to add support for POSIX-style signal handlers that provide
> > extended information on the signal and context. The SA_SIGINFO flag
> > is used to distinguish, as pointed out by François.
> Ping! A long time ago I posted this diff showing some work towards
> SA_SIGINFO support for x86. Haiku's lack thereof constitutes a source
> of great pain for porting signal-handling runtimes such as Mono and,
> apparently, Ruby.
> Ingo concluded in this thread that Haiku needed Real-Time Signal
> Support in terms of a signal queue for SA_SIGACTION to fill in the
> gaps of my patch.
> Am I seeing correctly that there has been no progress on this topic
> the last two years?


> Apart from recently changed VM includes, my patch still cleanly
> applies and has been rebased:
> http://dev.haiku-os.org/ticket/2695
> Could one of the core devs please take another look whether parts of
> the kernel-side implementation could be applied? Maybe with #if 0 or
> if (true) where the public headers intentionally do not define
> relevant types/values yet?

As long as the interesting part is not implemented I don't see point in 
applying the patch. Since I'm strongly opposed to making SA_SIGINFO visible 
before it actually works, most of the changes would indeed have to be "#if 
0"-ed. So we can just as well keep them as a patch attached to a ticket.

I don't even like the addition of <ucontext.h>. It's an utterless useless 
header as long as it is not backed by functionality, only adding the risk 
of tripping configure scripts that erroneously infer from the existence of 
the header that the features exist as well. More importantly though, the 
header was already marked obsolescent in 2004 and is no longer POSIX since 
2008. I would vote for removing it again.

CU, Ingo

Other related posts: