Re: SCO: "thread creation is about a thousand times faster than on native Linux"

From: Alan Cox (
Date: Thu Aug 24 2000 - 13:44:15 EST

> 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


        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
- 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
Please read the FAQ at

This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:14 EST