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

Date: Thu Aug 24 2000 - 14:05:03 EST

On Thu, Aug 24, 2000 at 08:23:34PM +0100, Alan Cox wrote:
> > 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.
> Assuming we queue signals to arbitary threads then a single thread causing all
> the open/close/read events would queue open/close/read events onto arbitary
> signal queues. So thread 1 might see open open and thread 2 see close read-ready

As far as I can understand POSIX specs, we have two choices.
Choice one is to make users figure it out. The signal handler wakes up,
gets a signal and has a queue of aio pointers to work with.
Choice two is to take advantage of the ambiguity in the specification
and deliver the signals only to the thread that initiates the operations.
Choice one, seems to give users a wider design space but it's rather
overkill to use both threads and asyn-io in one application.

> > Of course, you are violating POSIX, but only for a process that expects
> > to get non-POSIX semantics. Ordinary processes don't see this.
> But they can trigger it too. The signal to all members case for a couple of
> specific cases is the one thats cheap to evaluate and handle

My proposal, stupid as it may be, is that a process would have to
explictly ask for raw signals to get them.

And the non-cheap evaluation is figuring out which thread gets a signal
sent to root thread process. POSIX essentially requires that we offer
facility and it requires:
            somehow link all these processes together
            search for a process that is not blocking
            if no process can be found, queue and then when
            one of these "process-threads" unblocks, deliver.
            (so pthread_sigmask must enter the kernel and search
             all threads sharing the same "thread group" to see
             if there is a pending signal ... -- on a smp this
             is possibly horrendous.)

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