lkml.org 
[lkml]   [2001]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: signal dequeue ...

On 22-Jun-2001 Paul Menage wrote:
> In article <0C01A29FBAE24448A792F5C68F5EA47D120354@nasdaq.ms.ensim.com>,
> you write:
>>
>>Right, but the remaining signals are still pending. In your method, the
>>kernel doesn't know which were and which were not actually delivered.
>>
>
> You could add an SA_MULTIPLE flag to the sigaction() sa_flags, which
> permit the kernel to stack multiple signals up in this way for apps
> that guarantee not to misbehave. In do_signal()/handle_signal(), only
> allow a signal to be stacked on another signal if its handler has
> SA_MULTIPLE set. So non-stackable signals will always be the last
> signal frame of the stack to be entered, and it won't matter if they
> longjmp() out.
>
> Would the performance improvement from this be worthwhile? I imagine if
> you're handling a lot of SIGIO signals, the ability to batch up several
> signals in a single user/kernel crossing might be of noticeable benefit.

This could be a good idea but before moving a single hair I want to measure the
maximum ( and average ) queue length for rt signals.
In case this will be constantly > 1 to have a multiple signal dispatch will
save a lot of kernel-mode / user-mode switches.
Otherwise this will be files under NAI ( Not An Issue ) :)





- Davide

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:55    [W:0.051 / U:0.700 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site