> I don't understand this. If the user wants I/O to come in in order to
> a particular thread, the user can make it predictable. POSIX allows the
> user to have more than one thread accepting signals -- sent to the
> process.
You need queue ordering on the signal
> But maybe you know the answer to this question: when a _thread_ initiates
> an async I/O, does it want a signal sent to the thread (pthread_kill) or
> to the process?
Its sent to whoever you set to be signalled on that fd.
The problem is the ordering of queued events versus close/open. You have to
have a single time ordered view in order to resolve the event list
is
open 5
close 5
open 5
data ready
indicating the data is ready for the first or second user of the fd. Unless you
have a single ordered view of events you have a problem. So we need to keep
stuff queued sensibly. Its the IRQ controller problem, and the two traditional
solutions are
- Given signal goes to a given task
and
- Further signals go to the task that has a signal pending.
> > The root thread cant catch SIGSTOP and reprocess it
> Why not? We let the root thread register itself with the kernel asking
> for raw signals. Now the root thread is not getting POSIX signals, but
> it is invisible to any POSIX processes.
SIGSTOP is unmaskable. Its a major and rather unwise change to do otherwise,
then there is SIGKILL which has similar issues.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:14 EST