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

Date: Thu Aug 24 2000 - 13:21:37 EST

On Thu, Aug 24, 2000 at 07:44:15PM +0100, Alan Cox wrote:
> 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

If we have no threads this is not a problem. So can you explain to me
where the threads are in this example? I'm too dense to get your
telegraphy, have some pity.

> > > 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.

POSIX says that SIGSTOP is unnmaskable because we are worried about
poorly behaved user programs. But instead of putting POSIX "thread
group" logic in the kernel, it seems simpler to have a trusted thread
daemon that does the work and let that daemon get raw signals.

Of course, you are violating POSIX, but only for a process that expects
to get non-POSIX semantics. Ordinary processes don't see this.

Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.

- 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