Messages in this thread |  | | Subject | Re: SCO: "thread creation is about a thousand times faster than on native Linux" | Date | Thu, 24 Aug 2000 19:44:15 +0100 (BST) | From | Alan Cox <> |
| |
> 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/
|  |