Messages in this thread |  | | Date | Thu, 24 Aug 2000 13:05:03 -0600 | From | yodaiken@fsmlabs ... | Subject | Re: 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. 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/
|  |