[lkml]   [2002]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: context switch vs. signal delivery [was: Re: Accelerating user mode
From said:
> I'm glad we agree on that one :)

Yup, sorry. That test is wrong, and is slated to be fixed at some point.

> When the task is registered as socket owner and is just about to enter
> the kernel due to a syscall, it will stop with a SIGTRAP and the
> tracing kernel process will run sometime and see a SIGCHLD. But after
> the task stopped and before the kernel process can change SIGIO
> ownership back, a new interrupt could come in and the SIGIO would
> remain pending in the task's process until the task was scheduled to
> run next time.
> How do you solve this?

A couple of ways. The system call path can call sigio_handler to clear
out any pending IO. The SIGIO that was trapped in the process will cause
another call to sigio_handler which won't turn up any IO, but I don't
consider that to be a problem.

The kernel process can examine the signal pending mask of the process after
it has transferred SIGIO to itself. This can be done either through
/proc/<pid>/status or a ptrace extension, since we're happily postulating
new things for it to do anyway. If there is a SIGIO pending, it calls

Any other possibilities that you see?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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