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. www.fsmlabs.com www.rtlinux.com- 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