[haiku-bugs] Re: [Haiku] #2695: [XSI] Implement SA_SIGINFO for sigaction
- From: "bonefish" <trac@xxxxxxxxxxxx>
- Date: Tue, 06 Apr 2010 14:38:19 -0000
#2695: [XSI] Implement SA_SIGINFO for sigaction
---------------------------+------------------------------------------------
Reporter: andreasf | Owner: axeld
Type: enhancement | Status: reopened
Priority: normal | Milestone: R1
Component: System/POSIX | Version: R1/pre-alpha1
Resolution: | Keywords:
Blockedby: 1935 | Platform: All
Blocking: |
---------------------------+------------------------------------------------
Comment(by bonefish):
Replying to [comment:10 andreasf]:
> Following a discussion on HaikuPorts-devs about how to handle lack of
{{{SA_SIGINFO}}}, I've given this a new try. Not having implemented
{{{sigqueue}}} or {{{waitid}}}, I'm reopening this ticket.
I'd rather see the realtime signal support tackled (or at least designed)
en bloc to avoid surprises of the "oops, to add this feature we have to
rewrite the whole stuff" kind. While that is often not that case, we *do*
have a wonderfully complete and precise feature specification (except
maybe for the user debugger interface). So it would make most sense to
first go through the features and derive requirements for the kernel
implementation, and only afterwards design and implement the thing.
> Signals are actually queued in {{{signal.cpp}}} this time and the
faulting address of a {{{SIGSEGV}}} is stuffed into {{{si_addr}}} in
{{{vm.cpp}}}. The {{{x86/arch_thread.cpp}}} frame setup code is unchanged.
>
> Unfortunately it doesn't work yet, due to use of {{{malloc}}} while
interrupts disabled. It's probably not thread-safe either. Comments on how
to improve appreciated!
Welcome to kernel development! Invocation of malloc(), free(), or any
other function that uses locking primitives other than spinlocks is
forbidden when interrupts are disabled. Usually that means moving
allocations before disabling interrupts and postponing freeing until after
re-enabling them. I haven't investigated whether there is a reasonable
work-around in this case or whether we might have to rethink the locking
concept for a few major kernel locks (team and thread spinlock) first.
--
Ticket URL: <http://dev.haiku-os.org/ticket/2695#comment:11>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
