adam beberg writes on tue NUMBER sep NUMBER kragen sitaker wrote unix acquired nonblocking i o in the form of select about NUMBER years ago and solaris has had the particular aio_ calls we are discussing for many years select scaling is a joke at best and i know you know that poll is only a bit better not only do i know that the post to which you were responding explained that with somewhat more detail than a joke as you should know but evidently don t poll isn t even a bit better in fact it s about an order of magnitude worse for dense file descriptor sets which is the normal case except on operating systems where select isn t a system call but a library routine that calls poll very few applications need the aio_ calls essentially only high performance rdbms servers even benefit from them at all and most of those have been faking it fine for a while with multiple threads or processes this just provides a modicum of extra performance wrong it makes a huge difference in even what i consider small programs why don t you explain this in more detail although i don t have a copy of the spec handy i think the aio_ apis come from the posix spec ieee std NUMBER NUMBER NUMBER section NUMBER NUMBER NUMBER which is NUMBER years old and which i think documented then current practice they might be even older than that yes sgi has a patch to the linux kernel to implement the aio_ interfaces but it s still not built in who knows when it will be the point is it s not portable in either case you originally said could it be after NUMBER years without this feature unix finally catches up to windows and has i o that doesnt sic totally suck for nontrivial apps no way the point my point the point i was discussing please don t try to tell me you were trying to make a different point because i don t care is that you had no clue what you were talking about unix hasn t been without this feature and in fact has had it since you were in elementary school and operating systems without it don t totally suck for nontrivial apps for what it s worth glibc has actually implemented the aio_ calls for a while just in a way that doesn t scale to large numbers of concurrent i o requests i find references to the glibc implementation as far back as NUMBER and glibc NUMBER NUMBER NUMBER and i could probably find much earlier references if i had time URL more details at URL details on the sgi patch are at URL unix has been multiprocess since NUMBER and most unix implementations have supported multithreading for a decade or more and most unix is still kinda sorta supporting the pthreads posix interface each in their own NUMBER NUMBER implementation you re safe if you stick to the basics your original complaint was that unix didn t do multithreading or multiprogramming well now that i ve pointed out how obviously idiotic that claim is you ve amended your complaint now although individual unixes do these things well you complain that their implementations are not entirely conformant with the posix threads specification well that s probably true but i haven t written pthreads programs in c much myself so i can t confirm it from my own experience but even if it s true it s not a very good reason to prefer windows i m sure you can provide examples of bugs in particular threading implementations spare us just shut up kragen pobox com kragen sitaker URL edsger wybe dijkstra died in august of NUMBER the world has lost a great man see URL and URL for details 