The OS.IO.poll function in MLton's Basis library is probably implemented<br>incorrectly. I say "probably", because the basis library specification<br>leaves a lot to be desired.<br><br>The specification says
<br><br> infoToPollDesc pi<br> returns the underlying poll descriptor from poll information pi. <br><br>I would assume that this means that you get a poll descriptor ("events"<br>flags) that is *equal to* the corresponding poll descriptor that you gave
<br>to poll. In MLton's implementation this doesn't necessarily hold, because<br>the implementation derives a poll descriptor from the flags in the poll<br>information ("revents" flags).<br><br>Here is a simple example. Suppose we have (exactly one poll descriptor)
<br><br> val pds = [OS.IO.pollIn (OS.IO.pollOut (OS.IO.pollDesc ioDesc))]<br><br>and then execute<br><br> val ids = OS.IO.poll (pds, NONE)<br><br>I would assume that<br><br> map OS.IO.infoToPollDesc ids = pds<br><br>but this doesn't necessarily hold in MLton. In MLton's implementation,
<br>the left hand side may be equal to any one of<br><br> [OS.IO.pollIn (OS.IO.pollOut (OS.IO.pollDesc ioDesc))]<br> [OS.IO.pollIn (OS.IO.pollDesc ioDesc)]<br> [OS.IO.pollOut (OS.IO.pollDesc ioDesc)]<br> [OS.IO.pollDesc
ioDesc]<br><br>The last, perhaps surprising, case results from the possibility of<br>"revents" flags POLLERR, POLLHUP, and POLLNVAL, which may be set even if<br>the corresponding "events" flags aren't.
<br><br>All in all, this means that even if the poll descriptor list given to poll<br>contained no duplicates, it may be impossible to associate the returned<br>poll information values to the poll descriptors that you gave to poll.
<br><br>-Vesa Karvonen<br><br>