[lkml]   [2000]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: SCO: "thread creation is about a thousand times faster than on native Linux"
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

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