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/