Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Wed, 15 Sep 1999 18:59:53 +0100 (BST) | Subject | Re: High Performance I/O stuff (more) |
| |
Hi,
On Wed, 15 Sep 1999 00:06:59 -0700, "Jayson Nordwick" <nordwick@scam.xcf.berkeley.edu> said:
> Now, looking at POSIX.1b signals and signal queues and getting some > information from Stephen Tweedie it looks like completion ports are doable > without anything new, I think that I have decided.
You are missing the point...
> If you find an available signal, set the handler for it, the block it, > this signal number now effectively becomes the completion port. You then > can fcntl() a file descriptor with F_SETSIG and the signal number. Then to > fetch the blocked signals, use sigwaitinfo().
The point is that this _already works_. You get the fd in the siginfo's si_fd struct. What is missing right now is poll band information for si_band, but there are patches pending for that.
> The one drawback that I see to this is that it can only really handle > aio_{read,write}() and {read,write}()/fcntl(). Any other events such as > thread/child deaths cannot really be worked into this scheme unless you > could set the signal they deliver on termination.
Completion ports also don't implement things like child death notification until you implement child death notification completion ports. :) We already have a working model: if you want to add more completion events, then feel free to do so. You don't need to invent a new delivery mechanism.
> If you really wanted to, you could have signals delivered for the ability > to read/write to a file descriptor and then you would have Gaurav's model.
That is what happens today. We already have that model. That is what F_SETSIG does.
> Basically, unless anybody can see anything wrong with this get to work > implementing!
I already implemented it --- it is in 2.2.
--Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |