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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:14 EST