lkml.org 
[lkml]   [2009]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Signal from kernel space to user space
Mark Hounschell wrote:
> Clemens Ladisch wrote:
> > kill_pid_(info) is to be preferred over send_sig_info because it ensures
> > that the destination process has the same identity (a plain pid number
> > might have wrappend around and be in use by another process).
>
> Does that mean I can't assume my process pid will unique for the life of the process?

The pid _does_ uniquely identify your process. However, after the
process has died, it could be used for some new process, and
send_sig_info would happily kill the new process.

> > However, why are you using a signal? What information are you trying to
> > send, and why wouldn't eventfd or a plain device thaz becomes readable
> > be a better solution?
>
> If no "information" is required, which of these are the fastest, say
> from an interrupt handler?

If there really is no information, doing nothing would be fastest. ;-)

If you want to tell userland that some event has happened, the various
mechanisms are not much different as far as the kernel is concerned,
as long as you don't have many thousands of events per seconds; the
biggest problems for event delivery are scheduling the userland process
for execution and handling of the event.

Signals handlers interrupt any other userland code and therefore are
not allowed to do much; therefore, I would strongly prefer to use
some file handle that can be waited on with poll(). Furthermore,
poll() allows to wait for multiple handles, and does not have the
complexities of signal delivery and blocking. I would use signals only
if the handler must interrupt any other running code, and if the signal
can be handled completely without running into reentrancy problems.

It is possible to handle signals with poll() by using signalfd, but
when designing a new interface, one could just use eventfd instead.


Best regards,
Clemens


\
 
 \ /
  Last update: 2009-12-02 13:31    [W:0.052 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site