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

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