>Events could also (I haven't thought this out, so please forgive me if >there's an obvious bugaboo here) return additional information about the >descriptor/whatever. One nice possibility would be outgoing buffer space >on sockets. This may or may not be worth the coding effort. >
First, If you are using POSIX real time signals, you can get extra information by using sigwaitinfo(). In a somewhat nonportable fashion, the Linux people (Stephen Tweedie, in particular) added two things: (1) An fcntl() value called F_SETSIG that delivers a real time signal whenever data to the file descriptor is ready for read or write, (2) when the signal is delivered the si_band of the signal is filled in with the poll() values. >If implemented in a multiprocessor aware manner, events could also allow >for more parallelism that we have now. > Two of the strong benefits of asynchronous I/O over the nonblocking/select() is that (1) there is no context switch to send the data, since the kernle takes care (as opposed to the select() philosophy of the program taking care of it) and (2) if you are running on an MP machine, the kernel can be using one processor to take care of asynchronous data while the application uses the other. >-Chris > -jason To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
