[RFC] sigpending rework

[RFC] sigpending rework

[Kalaky]

Hello,

Currently, queued RT signals go into a list of pending signals
for a given task_struct (multiple RT signals can be queued).
When an process dequeues a signal through sigwaitinfo()
we must search the list for the given signal. This search is
always O(n) where n is the number of pending signals,
since we must go through all list members to ensure if
a signal number is still pending.

I'm working on converting the sigpending structure into a vector
of _NSIG sigqueue's for each signal number (which is quite a big
work), this way we can directly access each signal list, delivering
and checking any pending signals in a efficient manner.

Any thoughts ?

TIA,

Kalaky

Re: [RFC] sigpending rework

[Ulrich Drepper]

On Mon, 13 Dec 2004 21:06:08 -0200, Kalaky <kalaky@gmail.com> wrote:
 
> 
> I'm working on converting the sigpending structure into a vector
> of _NSIG sigqueue's for each signal number (which is quite a big
> work), this way we can directly access each signal list, delivering
> and checking any pending signals in a efficient manner.

This looks like a logical extension but the question is, is it worth
it?  I don't know about a case so far where this is a bottle neck. 
But any solution will cost every process, regardless of whether it
uses signals often or not.

So, if your solution can avoid or keep the cost very very low, it
might be worth using such a change.  Otherwise the ol' saying applies:
avoid signals at all costs.