--------------ms943A81F18588017EF60A686D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The API's I've seen proposed on this list have one fundamental problem:
They do not allow two independent libraries, both linked into the same
address space, to safely use the facility.
The get_next_event() API has one queue for the entire process. So if
two independent libraries both tried to use the interface, roughly half
of the event notifications would go to the wrong library.
POSIX async I/O has the same problem. As far as I know, there is no way
for a library to allocate a real-time signal number in a thread-safe
manner. If a library, say the BIND resolver, with an existing, frozen
interface wants to be reimplemented using POSIX async I/O, it runs a
credible risk of using the same signal as some other subsystem in the
same program. Also, the signal notification queue can overflow, leaving
the program in an essentially unrecoverable situation.
A read poll may be modeled as an asynchronous read of 0 bytes.
Unfortunately, on some systems a POSIX async read of 0 bytes completes
immediately, which is an absolutely useless semantic. Write polls are
generally made unnecessary by asynchronous I/O--if a program is
interested in writing, it generally knows what it wants to write, so it
can actually tell the kernel what that is. Unfortuanately, there are no
async equivalents of writev() or sendfile(), so if the process wants to
do an async sendfile() it ends up having to do the less efficient
write-poll-followed-by-nonblocking-sendfile()-and-loop. In that case,
one could perhaps model a write poll as an async write of 0 bytes, were
that not to also complete immediately.
NT has solved this whole class of problem with completion ports. They
handle the huge-number-of-connection problem well, they handle other
types of events, they are SMP-efficient. The concept goes back to the
days of VMS, why do unix kernel developers have such a big case of NIH?
These select() replacement proposals and POSIX aio have such limited
uses. They're crap.
--------------ms943A81F18588017EF60A686D
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIIJwYJKoZIhvcNAQcCoIIIGDCCCBQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BiEwggLUMIICPaADAgECAgIA2zANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ
BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u
bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0
IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05OTA2MTYyMjE2MTBaFw05OTEyMTMyMjE2MTBa
MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh
BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz
MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
uOdKuI9bAK274dB6KSMtdvM48YyQ1N5qTAoFSIBb9wZWctiAfo0ynJFP4fYBK3KmTN99A7/x
Uvu/3TJ/WoHg3P16gHEBtP31PPD2qv0LWm+V6W3fJbyOeempBnF3nAtUXPEqdQwQsKcbeiqC
j7O+ERlfhMJfd+5rjJ9R7yuSs18CAwEAAaNGMEQwEQYJYIZIAYb4QgEBBAQDAgSwMA4GA1Ud
DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTANBgkqhkiG9w0B
AQQFAAOBgQCqiRVQqw0adt0ufuWq6iMoG+Z8CcFKRibSFi9xJo/XBX26+ZutK04cTgA9k3O8
hnCRoMBH9CXzcl2XN0hd91OeOoWu7VDEI+3Dbvv0Gs2QEiJndXnm/008fcS7rSu5eb51mosr
ihF6HGWduZQTeewgz6f9UkEMMIIeQBho2ompvDCCA0UwggKuoAMCAQICAScwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp
ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG
cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv
bTAeFw05OTA2MDMyMjAwMzRaFw0wMTA2MDIyMjAwMzRaMIGTMQswCQYDVQQGEwJVUzELMAkG
A1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25s
aW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQg
Q2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDi718s
dkOJSxpfs+X4qm+LL4FNZ/+9Sg9jLsTchfaeLEkmIP8AF+SIiGne/YNX4KMRGRGq1ty877PS
FS5Uxm58v9m5w0bTCQWE5VNcSO2EhZoOOz0WB1zws3mrmhClvMGk0XhMBuVkQfwFJWMm6+8M
x25UoYzOVFe2H5LashJLjQIDAQABo2kwZzASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQW
MBQGCCsGAQUFBwMEBggrBgEFBQcDAjARBglghkgBhvhCAQEEBAMCAQIwHwYDVR0jBBgwFoAU
cknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAulB9/ACy/0G0Bwg5DCH0
WUkXCMyO088MVvFv6AsaaWLrBoJbaawdhCcGOckOfjUT0H7Aj5xYfAMxLIcQ1WI7cNUOsWSA
NE5Z+sZZ5kbeTmgIdUD1HYwp1q53rck9aeRAjUSXRm++esBYpLEfaqcPKVGKgQ0pjp3kDzML
j40kPewxggHOMIIBygIBATCBmjCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYD
VQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAXBgNV
BAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRlIEF1
dGhvcml0eQICANswCQYFKw4DAhoFAKCBijAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw05OTA5MTAyMTQwNTNaMCMGCSqGSIb3DQEJBDEWBBRwDwjB0tVUcs1L
IFNgju2JMapZ1jArBgkqhkiG9w0BCQ8xHjAcMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA
gDANBgkqhkiG9w0BAQEFAASBgGiqIYystSCF1+o5qngYraOLIi9OvlFeZX3oTjOMr4iUyDVV
1T0p84M7ijToJ+9qABKNSuv+NMDdnEgroM6dVLSaSx6hzvhUrsxaKS9Y4vc1MXnPTkVLoDk0
26VHWUeJyVhQ+cmWxgdSzh4o01Mn3zeQsYmy6JUF8Tr8Kb8Xg1PK
--------------ms943A81F18588017EF60A686D--
-
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/